<html><head></head><body>That firewall reloading is due to comcast unnecessarily spamming ras every 3 seconds. We already filter it down to one reload per minute. I prepared another filter yesterday which will filter out updates that dont change anything but adress / route timers. So expect some solution for this reload spam in the coming days.<br><br><div class="gmail_quote"><br>
<br>
Dave Taht <dave.taht@gmail.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">I just filed bug <a href="http://www.bufferbloat.net/issues/438">http://www.bufferbloat.net/issues/438</a> on this issue<br />after working with matt until the wee hours.<br /><br />I have to take a couple packet captures next.<br /><br />To copy from the bug report:<br /><br />On the plus side:<br /><br />comcast ipv6 had been working fine between august and december on<br />cerowrt 3.10.7 (?)<br /><br />we do get an external IPv6 address AND /60 dhcpv6-pd delegation from<br />comcast, and distribute the /64s to each of the subnets on cero. The<br />resulting native ipv6 connection works for getting into the router<br />itself and stays up all night...<br /><br />On the minus side(s)<br /><br />1) The AAAA record on the wan interface (ge00) is withdrawn and<br />renewed every minute or two. This triggers reloading the firewall,<br />which really isn't something you want happening every minute or two.<br />The delegation seems to persist longer than that,
but...<br /><br />2) We do not get dnsmasq distributing that /64 on any interface.<br />Interestingly if you manually add a new IPv6 address from that range<br />(say, whatever::2/64) dnsmasq picks it up and starts serving ipv6<br />addresses. (theory: we don't have that ipv6 delegation long enough for<br />dnsmasq to see it before they are withdrawn)<br /><br />3) We get plenty of instruction traps IF you delegate to the wireless<br />and use it.<br />(there may be other factors on the instruction traps so don't take the<br />above as canon), but Running all night with just the ::2 manually<br />inserted on ethernet results in no instruction traps (but there was no<br />traffic either). running with with the manual ::2/64 inserted does<br />result in routable, working, ipv6 subnet addresses that dnsmasq sees<br />and distributes from.<br /><br />4) tweak: ge01 needs to be added to the firewall rules for wan. maybe.<br /><br />The net result is unusable native ipv6 on comcast
. (<a
href="http://comcast6.net">comcast6.net</a> is<br />also reporting unusable ipv6 on wireless on the xbox 1, and I don't<br />know if that's related)<br /><br />Working theories: A) is we have an endianess problem on parsing<br />dhcpv6-pd from comcast for the timeout, B) comcast has an endianess<br />problem C) we are not keeping properly track of the ipv6 address<br />assignment and/or lease length. D) Comcast isn't assigning ipv6<br />external addresses and subnets for more than a minute. E) we have some<br />problem on the wireless side in particular (but that seems independent<br />of the problem)<br /><br />We have all generally been running fine with ipv6 tunneled through hurricane, so<br />my assumption is that this is something specific to the directly connected ge00<br />interface, in negotiating something with the upstream dhcpv6 and<br />dhcpv6-pd stuff.<br /><br />So here's one of the symptoms. I have some packet captures and straces to do:<br /><br />Sat Jan 18 1
3:18:55
2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:19:57 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:21:01 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:22:02 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:23:02 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:24:04 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:25:04 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:25:45 2014 <a href="http://daemon.info">daemon.info</a> dnsmasq-dhcp3318:<br />RTR-ADVERT 2601:9:8580:c32::<br />Sat Jan 18 13:26:07 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:27:09 2014 user.notice firewall: Reloading fi
rewall
due<br />to ifupdate of ge01 ()<br />Sat Jan 18 13:28:11 2014 user.notice firewall: Reloading firewall due<br />to ifupdate of ge01 ()<br /><br /><br />On Sat, Jan 18, 2014 at 9:23 AM, Steven Barth <cyrus@openwrt.org> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Fyi as stated earlier i made the switch to odhcpd yesterday. With that i<br />also switched routing from individual tables to source-constrained routes in<br />the maintable.<br /><br />Cheers,<br />Steven<br /><br /><br /><br /><br />Dave Taht <dave.taht@gmail.com> schrieb:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On Fri, Jan 17, 2014 at 1:52 AM, Matt Mathis <mattmathis@google.com><br />wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">I'm final
ly
getting back to this.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">Hmm. if you uncomment everything in /etc/dnsmasq.conf and restart<br />dnsmasq what happens? If you have got /64s you would end up doing<br />slaac and ra announcements via dnsmasq in this case.<br /><br />That was on by default before (and what was tested in feburary). Later<br />on 6relayd started having a race with it and seemed to be "the<br />future", so I disabled the dnsmasq version, thinking that 6relayd was<br />the answer. It's entirely possible that's<br />merely configured wrong.</blockquote><br /><br /><br />Now I get global /64's on my LAN interfaces, but I am still not answering<br />dh<br />cp6 for<br />attached hosts. I retried both version of the 6relayd init<br />script....<br /><br />dnsmasq.conf contains:<br />enable-ra<br />dhcp-range=::1,::400,constructor:se00,ra-names,ra-stateless<br
/>dhcp-range=::1,::400,constructor:sw00,ra-names,ra-stateless<br />dhcp-range=::1,::400,constructor:gw00,ra-names,ra-stateless<br />dhcp-range=::1,::400,constructor:sw10,ra-names,ra-stateless<br />dhcp-range=::1,::400,constructor:gw10,ra-names,ra-stateless<br /><br /><br />I am running: Linux cerowrt 3.10.24 #1 Tue Dec 24 10:50:15 PST 2013.....<br />which might be just a bit too fresh.... Would you suggest another?</blockquote><br /><br />You are not getting slaac either?<br /><br />An ifconfig on an interface and a packet dump of ipv6 packets would be<br />helpful.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">I have a spare 3700, so I think I will try some alternate vintages.<br /><br />Thanks,<br />--MM--<br />The<br />best way to predict the future is to create it. - Alan Kay<br /><br /><br />Privacy matters! We know from recent events that people are using our<br />services to speak in
defiance of unjust governments. We treat privacy<br />and<br />security as matters of life and death, because for some users, they are.<br /><br /><br />On Sun, Jan 5, 2014 at 7:48 PM, Dave Taht <dave.taht@gmail.com> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;">On Sat, Jan 4, 2014 at 1:30 AM, Steven Barth <cyrus@openwrt.org> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;">On 03.01.2014 19:43, Dave Taht wrote:<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">I was also experiencing a race condition with dnsmasq, while I had it<br />enabling<br />ra<br />and<br />dhcpv6 via dnsmasq. At the moment that's turned off by default,<br />but<br />I did rather prefer having dns names for my ipv6
addresses...</blockquote><br /><br />Well 6relayd and odhcpd collect hostnames of clients acquired via<br />stateful<br />DHCPv6 and export them to dnsmasq in an additional hostfiles. At least<br />that<br />seemed to work when I last tried it a few months ago. The only<br />disadvantage<br />is that there is no "ra-names" feature there.</blockquote><br /><br />Getting to names from dhcpv4 to slaac was a neat hack and a potential<br />RFC. So i figure spending the time to add the same functionality into<br />into something other than dnsmasq would be useful towards writing that<br />rfc.<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">is there a good way for 6re<br />layd<br />and dnsmasq-dhcpv6 to co-exist?</blockquote><br /><br />Ideally they could coexist in a way that you c
ould
select dnsmasq and /<br />or<br />odhcpd for different interfaces on the same machine. odhcpd supports<br />that<br />but dnsmasq the last time I've looked seemed to use a single socket<br />binding<br />to all interfaces for DHCP/v6 which prevents coexistance from working<br />correctly because odhcpd / 6relayd can't bind the socket after dnsmasq<br />did<br />and vice versa.<br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">Feel free to provide me with some debugging information of the system<br />while<br />PD fails for you so I can have a look at the probable cause:<br /><br />* "ifstatus ge00" (replace ge00 with your IPv6 upstream interface)<br />* "ip addr list dev<br />ge01"<br />(replace ge01 with the interface your<br />downstream<br />router is connected)<br />* "ps
| grep
6relayd"<br /><br />Anyway I will migrate all the stuff to odhcpd soon (it's successor<br />which<br />shares a good part of the codebase but is a bit better integrated<br />with<br />the<br />rest of the environment).</blockquote><br /><br />same question re dnsmasq.</blockquote><br /><br />Yeah as pointed out coexistence is a matter of binding sockets. odhcpd<br />will<br />bring the functionality of dynamically enabling / disabling DHCPv4/v6<br />on<br />interfaces without restarting the daemon and loosing state. This is one<br />of<br />the main reasons for the change and very much eases things for<br />high-level<br />protocols that do dynamic wan/lan detection.<br /><br /><br />Cheers,<br /><br />Steven<br /><br /><br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">Regard
s,<br
/><br />Steven<br /><br /><br /><br />On 03.01.2014 18:31, Dave Taht wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">On Fri, Jan 3, 2014 at 11:50 AM, cb.list6 <cb.list6@gmail.com><br />wrote:<br /><br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">On Fri, Jan 3, 2014 at 8:40 AM, Dave Taht <dave.taht@gmail.com><br />wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">At one level I am happy to figure out this is a recently<br />introduced<br />bug.<br /><br />On the other hand I am not sure if it is 6relayd.<br /><br />What version of cero was working for you?</blockquote><br /><br /><br />I am not entirely sure, but i think it was from September.<br /><br />CB</blockquote><br /><br />At the moment I lack the ability to d
ebug
the breakage in ipv6<br />dhcp-pd<br />(which is odhcpd) (I am travelling).<br /><br />I will on my next stop next week (tuesday) setup a dhcpv6pd server<br />and<br />see what I can see.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">On Jan 3, 2014 12:21 AM, "cb.list6" <cb.list6@gmail.com> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ccc; padding-left: 1ex;">Hi,<br /><br />I have been using CeroWRT on Comcast with a 3800 for about 6<br />month.<br />The<br />DHCP-PD config has always been a little unstable for me, but<br />working.<br /><br />I recently upgraded to:<br /><br />root@cerowrt:/etc/config# uname -a<br />Linux cerowrt 3.10.24 #1 Tue Dec 24 1<br />0:50:15<br />PST 2013 mips<br />GNU/Linux<br /><br />My WAN
gets a
/128, but i cannot get DHCP-PD to work to get<br />addresses<br />on<br />the rest of my interfaces. The router does seem to have good<br />IPv6<br />access.<br /><br /><br />I fiddled with the 6relayd config and came up with this, but it<br />does<br />not<br />work. Any pointers on how to get this back on track? The result<br />of<br />the<br />below config is that the /128 from the WAN interfaces is now<br />present<br />on<br />all<br />the interfaces but my attached computers get no addresses.<br /><br /><br />config server 'default'<br />option rd 'server'<br />option dhcpv6 'server'<br />option management_level '1'<br />list network 'ge01'<br />list network 'gw00'<br />list network 'gw01'<br />list network 'gw10'<br />list network 'gw11'<br />list network 'se00'<br />list network 'sw00'<br />list network 'sw10'<br />option fallback_relay 'rd dhcpv6 ndp'<br />option master 'ge00'<br /><br />root@cerowrt:/etc/config# un<br />ame<br />-a<br /><br /><hr /><br /><br
/>Cerowrt-devel mailing list<br />Cerowrt-devel@lists.bufferbloat.net<br /><a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a></blockquote><br /><br /><br /><br /><br /><br /><br /><br /><br /></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote>--<br />Dave Täht<br /><br />Fixing bufferbloat with cerowrt:<br /><a href="http://www.teklibre.com/cerowrt/subscribe.html">http://www.teklibre.com/cerowrt/subscribe.html</a></blockquote><br /><br /><br /><br /><br /><br /></blockquote>--<br />Dave Täht<br /><br />Fixing bufferbloat with cerowrt:<br /><a href="http://www.teklibre.com/cerowrt/subscribe.html">http://www.teklibre.com/cerowrt/subscribe.html</a></blockquote><br /><br /><br /></blockquote>-- <br />Dave Täht<br /><br />Fixing bufferbloat with cerowrt: <a href="http://www.teklibre.com/cerowrt/subscribe.html">http://www.teklibre.com/cerowrt/subscribe.html</a><br
/></pre></blockquote></div></body></html>