Bug #406

I am dealing with three additional different bugs here.

0) quagga is not pushing the 6to4 default route out to other babel nodes.

1) On the local interface,
the following syntax only adds one 2002:: based addresses to the listed
interfaces. (se00)

config interface ‘ge01’
option proto ‘6to4’
option adv_subnet ‘1’
option wan_device ‘ge00’
option metric ‘1’
option ttl ‘64’
list adv_interface ‘gw00’
list adv_interface ‘gw10’
list adv_interface ‘se00’
list adv_interface ‘sw00’
list adv_interface ‘sw10’

Interestingly, although luci will write this syntax, when it re-reads it only finds the first (gw00) interface. (see pic)

(it will also read the old syntax and convert to this)

I have been refreshing luci a lot, but somehow perhaps I’m out of sync? (no,
my last commit was 6c6af10f0859cbe5d61f5d2d60dfc9ea5215285e

And regardless only the third (se00) of these interfaces gain a 2002 address.

2) This generates a radvd file for the one interface that works as below.
Perhaps I need to put in a default route statement explicitly?

interface se00
{
AdvLinkMTU 1480;
AdvDefaultPreference medium;
IgnoreIfMissing on;
AdvSendAdvert on;
AdvOtherConfigFlag on;
AdvSourceLLAddress on;

prefix 2002:328a:a616:1::¹⁄₆₄
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};

RDNSS fe80::204e:7fff:fe4a:9623
{
};

DNSSL home.lan
{
};
};

The one client connected that way (haven’t verified it’s functionality)
isn’t getting out.

3) when netifd runs it deletes up the addresses gained via ahcp, wiping out the mesh.

config interface ‘gw01’
option proto ‘ahcp’

config interface ‘gw11’
option proto ‘ahcp’

Both I and jow changed netifd to insert user routes as static (which is arguably more correct, anyway)

But although I changed quagga to distribute static as well, it still doesn’t pick up the 6to4-ge01 default route for ipv6. I tried adding the device to the quagga “network” stanza, to no luck… It is not shown as an export from vtysh, either.

0.0.0.0/0 metric 0 (exported)
50.138.160.0/21 metric 0 (exported)
192.168.1.0/27 metric 0 (exported)
192.168.1.⁶⁴⁄₂₇ metric 0 (exported)
192.168.1.⁹⁶⁄₂₇ metric 0 (exported)
192.168.1.¹²⁸⁄₂₇ metric 0 (exported)
192.168.1.¹⁶⁰⁄₂₇ metric 0 (exported)
192.168.1.²²⁴⁄₃₂ metric 0 (exported)
::50.138.166.²²⁄₁₂₈ metric 0 (exported)
2002::/16 metric 0 (exported)
2002:328a:a616:bab5::¹⁄₁₂₈ metric 0 (exported)

Perhaps I can statically add it to the zebra config?

moving on to the other issues…

the 6to4 portion of the netifd scripts does not do address assignment. I’m not sure if it should, actually, when controlled by the adv_subnet variable. Perhaps a new variable, “assign_subnet” would be more appropro, or rs solicitations enabled in this case to automagically get a slaac address…

(btw, I like the scripts they are very clean and easy to read)

and have no idea how to tell it to ignore interfaces run with ahcp.

I was successfully able to propagate a default ipv6 route for 6to4 via adding
a stanza in zebra.conf

interface 6to4-ge01
ipv6 route ::/0 2002:c058:6301::

I’m not certain I wanted to do it that way (certainly I don’t want to announce routes via that interface)

Jow fixed portions of this bug (1 and 2)

In packages:

proto/6x4: cast 6to4 adv_interface to string when saving to uci, fixes 6in4.

Jow moved netifd to install userspace routes as static

[package] netifd: bump to git head, userspace routes are installed with RTPR_STATIC

This did not actually fix quagga. I put in a workaround in #note-3 - but I’m not happy with having to embed the
anycast route there, even if it is pretty generic…

This leaves netifd mucking with ahcpd managed interfaces when it shouldn’t be as the last big remaining issue here.

Thx jow for leaping on this.

Could you post the output of “show ipv6 route” vtysh command with and without the workaround?

On Wed, Sep 19, 2012 at 3:58 PM, Chris Lawrence lordsutch@gmail.com wrote:
> I’ve only noticed one real problem thus far: radvd is still
> advertising incorrect subnet addresses for 6to4 connections (addresses
> that start with 0:0:0:\$adv_subnet, which clearly are wrong since all
> the addresses should be under 2002: to be routable on the ipv6
> Internet). The fix is simple: in /lib/netifd/proto/6to4.sh, line 162
> should read:
>
> “\$wancfg” “\$subnet6” \
>
> instead of the printf call that’s there now. This is probably an
> upstream OpenWRT problem too.

Actually, no, the correct line would be:

set_6to4_radvd_prefix “\$sid” “\$adv_interface” \
“\$wancfg” “\$(printf “%s:%x::/64”
\$prefix6 \$adv_subnet) \
“\$adv_valid_lifetime” “\$adv_preferred_lifetime”

arguably “subnet6” is misnamed.

There is another bug in this script in correctly adding multiple
interfaces. It succeeds on the first, but not the rest, and thus far I
can’t figure out why.

There is another bug in that arguably the interface itself should have
a prefix lifetime (monitored somehow) and mtu set and I’d argue for
marking it secondary in the hope that someday real ipv6 addresses
would become common.

And last bug, in that with the latest quagga OR dnsmasq, radvd is not
needed, except for detecting and generating the 6to4 prefix.

Chris

Setting the radvd adv subnet with leading zeros is deliberate and not a bug.
Thats a special feature of radvd, it will populate the leading zeros with the prefix of the Base6to4 interface specified in the same prefix section. See the radvd man page for details on this.

I have no idea what’s going to happen vs a vs dnsmasq vs quagga vs the new relay6d stuff.

I’m just happy radvd is going to go away. soon.