[Babel-users] ipv6_subtrees fixes queued for 3.10.10 (probably)

[Dave Taht]

On Thu, Aug 22, 2013 at 11:37 AM, Dave Taht <dave.taht at gmail.com> wrote:

> And, sigh. I restart quagga-RE on the new release, where I have two
> identical /128s on the same interfaces (gw01 and gw11) and I get:
>
> 2013/08/22 18:19:08 BABEL: setsockopt(IPV6_JOIN_GROUP) on interface
> 'gw11': Address already in use
>
> I don't know if this is relevant to the ipv6 subtrees discussion, but this
> was the only major patch change between cero's releases, so I'm inclined to
> suspect this. I note that the fe80 addresses are all different (at least on
> this device, but perhaps there is a conflict elsewhere, checking), and this
> happens with or without assigned by ahcp /128s on the interfaces.
>
> Reverting.
>
> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.9-1/ is that
> build (which has other problems in things like dhcp userspace, I wouldn't
> recomend you use it)
>
>
>
> On Wed, Aug 21, 2013 at 3:01 PM, Dave Taht <dave.taht at gmail.com> wrote:
>
>> I've got this in the next version of cerowrt and it looks like it is also
>> targetted for -stable. I see the babels branch has been quiet since jul 12,
>> and I
>> figure mattieu and juliusz are still in recovery from ietf.
>>
>> So I hope this can be made to work, my question though is what sort
>> of sane way can working ipv6_subtrees be done at runtime be determined?
>>
>> --
>>
>
Poking into this a little more, I have another device (a nanostation M5)
running 3.10.3 reporting a similar problem, except this one is bad dad on
the fe80 address, on an ethernet, not wireless port.

So it isn't IPv6 subtrees, but is a 3.10 or hw issue.

And - dang mesh networking! I never noticed it. It's been routing through 5
hops of the local network to get back to that device.

So, anyway, I see in that's log

Thu Aug 22 12:37:02 2013 auth.info kernel: [524566.656250] IPv6: eth1: IPv6
duplicate address 2001:470:8236:cccc:cccc:22ff:fea8:a2c0 detected!

It's running babeld (not quagga), which isn't reporting any errors.

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:470:8236:cccc:cccc:22ff:fea8:a2c0/128 scope global tentative
dadfailed
       valid_lft forever preferred_lft forever
    inet6 fe80::27:22ff:fea9:a2c0/64 scope link tentative dadfailed
       valid_lft forever preferred_lft forever

There is only one device on the other side of that ethernet, and it doesn't
share the same fe80. Even more curiously, there are multiple devices
running that version of the code that don't have this problem.

So I'm willing to put this down to a false alarm, and some other (weird)
problem.

however just to be sure, I'm reverting ipv6 subtrees in the next cero
build. I will not be able to test it til sunday however.

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/babel-users/attachments/20130822/cbde53ae/attachment.html>