<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 22, 2013 at 11:37 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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:<br>
<br>2013/08/22 18:19:08 BABEL: setsockopt(IPV6_JOIN_GROUP) on interface 'gw11': Address already in use<br>
<br></div>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.<br>
<div><br></div><div>Reverting.<br></div><div><br><a href="http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.9-1/" target="_blank">http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.9-1/</a> is that build (which has other problems in things like dhcp userspace, I wouldn't recomend you use it)<br>
<br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 3:01 PM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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<br>
figure mattieu and juliusz are still in recovery from ietf.<br>
<br></div>So I hope this can be made to work, my question though is what sort<br>of sane way can working ipv6_subtrees be done at runtime be determined? <br clear="all"><span><font color="#888888"><div><div>
<br>-- </div></div></font></span></div></blockquote></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">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. <br>
<br>So it isn't IPv6 subtrees, but is a 3.10 or hw issue.<br>
<br>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.<br><br>So, anyway, I see in that's log<br><br>Thu Aug 22 12:37:02 2013 <a href="http://auth.info" target="_blank">auth.info</a> kernel: [524566.656250] IPv6: eth1: IPv6 duplicate address 2001:470:8236:cccc:cccc:22ff:fea8:a2c0 detected! <br>
<br>It's running babeld (not quagga), which isn't reporting any errors. <br><br>3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000<br> inet6 2001:470:8236:cccc:cccc:22ff:fea8:a2c0/128 scope global tentative dadfailed <br>
valid_lft forever preferred_lft forever<br> inet6 fe80::27:22ff:fea9:a2c0/64 scope link tentative dadfailed <br> valid_lft forever preferred_lft forever<br><br clear="all"></div><div class="gmail_extra">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. <br>
<br></div><div class="gmail_extra">So I'm willing to put this down to a false alarm, and some other (weird) problem.<br><br>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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">
-- <br>Dave Täht<br><br>Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html" target="_blank">http://www.teklibre.com/cerowrt/subscribe.html</a>
</div></div>