From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0474821F113; Sat, 18 Jan 2014 07:16:49 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id w61so5659364wes.30 for ; Sat, 18 Jan 2014 07:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PtrW/9yooICQjbFfBU2a4BIfb7MwWQNNP1CegsRb7jI=; b=cXgdakXe/rk4afMZY/pDWYlrZiw8mlVGHsav4vPcOgOJXcM/kwSoY5QTZKsF2buy57 z8v3EuPtUl1YafQsHbp9OwlZtOfxl2QVdbnIM/RTLmjBOd94TL9rP1FicdcwpkkGEXXw 9raoFpd54OMJbCTjz0HvMWPJhOzpJ/1gQGqqemzFBcwjtVLM9RRrUn9K4ANMfvZnLsDb U6P5b5DQjffu5BvqNgVbCmt7r+RBtS4vKf5RADngL5Qn1QZDqRTIzOhZRIxQu9Kazv+3 mcdSNkaxhgq+qY85uLMhKvMNhsm4KswcOQOSdIGBbMb/kwm+439P2guZ2HXL2urYnh7A nPwA== MIME-Version: 1.0 X-Received: by 10.180.211.39 with SMTP id mz7mr2905471wic.53.1390058207950; Sat, 18 Jan 2014 07:16:47 -0800 (PST) Received: by 10.217.123.69 with HTTP; Sat, 18 Jan 2014 07:16:47 -0800 (PST) Date: Sat, 18 Jan 2014 10:16:47 -0500 Message-ID: From: Dave Taht To: Steven Barth , cerowrt@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cb.list6" , Matt Mathis , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Bug #438] 6relayd X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 15:16:57 -0000 On Sat, Jan 18, 2014 at 9:46 AM, Steven Barth wrote: > That firewall reloading is due to comcast unnecessarily spamming ras ever= y 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 relo= ad > spam in the coming days. In looking over the packet captures I don't see any dhcpv6 requests going o= ut so we are holding onto the assigned external address... 3: ge00: mtu 1500 qlen 1000 inet6 2001:elided/128 scope global dynamic valid_lft 304731sec preferred_lft 304731sec inet6 fe80:elided/64 scope link valid_lft forever preferred_lft forever but in order to see dnsmasq advertise anything Sat Jan 18 15:04:59 2014 daemon.info dnsmasq-dhcp[3318]: RTR-ADVERT(se00) 2601:elided:: I'd had to add a static address to the interface 2: se00: mtu 1500 qlen 1000 inet6 2601:elided::2/64 scope global valid_lft forever preferred_lft forever added this manually and dnsmasq did router advertisements inet6 2601:elided::1/64 scope global dynamic valid_lft 304621sec preferred_lft 304621sec # added by the dhcpv6 cl= ient Is the once a minute update of the latter fooling dnsmasq (I'd tried 6relayd too, but it waslate) into not sending out a RTR-ADVERT? For example I left the wireless interface up but it has never managed to send a RTR-ADVERT: 16: sw00: mtu 1500 qlen 1000 inet6 2601:elidedbutdifferent::1/64 scope global dynamic valid_lft 304333sec preferred_lft 304333sec (I am still grumpy at the prospect of someone renumbering my network every 84 hours, much less once a minute) ---------- Forwarded message ---------- From: Steven Barth Date: Sat, Jan 18, 2014 at 9:46 AM Subject: Re: [Cerowrt-devel] 6relayd To: Dave Taht Cc: Matt Mathis , "cb.list6" , "cerowrt-devel@lists.bufferbloat.net" 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. > > > Dave Taht schrieb: >> >> I just filed bug http://www.bufferbloat.net/issues/438 on this issue >> after working with matt until the wee hours. >> >> I have to take a couple packet captures next. >> >> To copy from the bug report: >> >> On the plus side: >> >> comcast ipv6 had been working fine between august and december on >> cerowrt 3.10.7 (?) >> >> we do get an external IPv6 address AND /60 dhcpv6-pd delegation from >> comcast, and distribute the /64s to each of the subnets on cero. The >> resulting native ipv6 connection works for getting into the router >> itself and stays up all night... >> >> On the minus side(s) >> >> 1) The AAAA record on the wan interface (ge00) is withdrawn and >> renewed every minute or two. This triggers reloading the firewall, >> which really isn't something you want happening every minute or two. >> The delegation seems to persist longer than that, >> but... >> >> 2) We do not get dnsmasq distributing that /64 on any interface. >> Interestingly if you manually add a new IPv6 address from that range >> (say, whatever::2/64) dnsmasq picks it up and starts serving ipv6 >> addresses. (theory: we don't have that ipv6 delegation long enough for >> dnsmasq to see it before they are withdrawn) >> >> 3) We get plenty of instruction traps IF you delegate to the wireless >> and use it. >> (there may be other factors on the instruction traps so don't take the >> above as canon), but Running all night with just the ::2 manually >> inserted on ethernet results in no instruction traps (but there was no >> traffic either). running with with the manual ::2/64 inserted does >> result in routable, working, ipv6 subnet addresses that dnsmasq sees >> and distributes from. >> >> 4) tweak: ge01 needs to be added to the firewall rules for wan. maybe. >> >> The net result is unusable native ipv6 on comcast >> . (comcast6.net is >> also reporting unusable ipv6 on wireless on the xbox 1, and I don't >> know if that's related) >> >> Working theories: A) is we have an endianess problem on parsing >> dhcpv6-pd from comcast for the timeout, B) comcast has an endianess >> problem C) we are not keeping properly track of the ipv6 address >> assignment and/or lease length. D) Comcast isn't assigning ipv6 >> external addresses and subnets for more than a minute. E) we have some >> problem on the wireless side in particular (but that seems independent >> of the problem) >> >> We have all generally been running fine with ipv6 tunneled through >> hurricane, so >> my assumption is that this is something specific to the directly connect= ed >> ge00 >> interface, in negotiating something with the upstream dhcpv6 and >> dhcpv6-pd stuff. >> >> So here's one of the symptoms. I have some packet captures and straces t= o >> do: >> >> Sat Jan 18 1 >> 3:18:55 >> 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:19:57 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:21:01 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:22:02 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:23:02 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:24:04 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:25:04 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:25:45 2014 daemon.info dnsmasq-dhcp3318: >> RTR-ADVERT 2601:9:8580:c32:: >> Sat Jan 18 13:26:07 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> Sat Jan 18 13:27:09 2014 user.notice firewall: Reloading fi >> rewall >> due >> to ifupdate of ge01 () >> Sat Jan 18 13:28:11 2014 user.notice firewall: Reloading firewall due >> to ifupdate of ge01 () >> >> >> On Sat, Jan 18, 2014 at 9:23 AM, Steven Barth wrote: >>> >>> Fyi as stated earlier i made the switch to odhcpd yesterday. With that = i >>> also switched routing from individual tables to source-constrained rout= es >>> in >>> the maintable. >>> >>> Cheers, >>> Steven >>> >>> >>> >>> >>> Dave Taht schrieb: >>> >>>> On Fri, Jan 17, 2014 at 1:52 AM, Matt Mathis >>>> wrote: >>>> >>>>> I'm final >>>>> ly >>>>> getting back to this. >>>>> >>>>>> Hmm. if you uncomment everything in /etc/dnsmasq.conf and restart >>>>>> dnsmasq what happens? If you have got /64s you would end up doing >>>>>> slaac and ra announcements via dnsmasq in this case. >>>>>> >>>>>> That was on by default before (and what was tested in feburary). Lat= er >>>>>> on 6relayd started having a race with it and seemed to be "the >>>>>> future", so I disabled the dnsmasq version, thinking that 6relayd wa= s >>>>>> the answer. It's entirely possible that's >>>>>> merely configured wrong. >>>>> >>>>> >>>>> >>>>> >>>>> Now I get global /64's on my LAN interfaces, but I am still not >>>>> answering >>>>> dh >>>>> cp6 for >>>>> attached hosts. I retried both version of the 6relayd init >>>>> script.... >>>>> >>>>> dnsmasq.conf contains: >>>>> enable-ra >>>>> dhcp-range=3D::1,::400,constructor:se00,ra-names,ra-stateless >>>>> dhcp-range=3D::1,::400,constructor:sw00,ra-names,ra-stateless >>>>> dhcp-range=3D::1,::400,constructor:gw00,ra-names,ra-stateless >>>>> dhcp-range=3D::1,::400,constructor:sw10,ra-names,ra-stateless >>>>> dhcp-range=3D::1,::400,constructor:gw10,ra-names,ra-stateless >>>>> >>>>> >>>>> I am running: Linux cerowrt 3.10.24 #1 Tue Dec 24 10:50:15 PST >>>>> 2013..... >>>>> which might be just a bit too fresh.... Would you suggest another? >>>> >>>> >>>> >>>> You are not getting slaac either? >>>> >>>> An ifconfig on an interface and a packet dump of ipv6 packets would be >>>> helpful. >>>> >>>>> I have a spare 3700, so I think I will try some alternate vintages. >>>>> >>>>> Thanks, >>>>> --MM-- >>>>> The >>>>> best way to predict the future is to create it. - Alan Kay >>>>> >>>>> >>>>> Privacy matters! We know from recent events that people are using ou= r >>>>> services to speak in >>>>> defiance of unjust governments. We treat privacy >>>>> and >>>>> security as matters of life and death, because for some users, they >>>>> are. >>>>> >>>>> >>>>> On Sun, Jan 5, 2014 at 7:48 PM, Dave Taht wrote= : >>>>> >>>>>> On Sat, Jan 4, 2014 at 1:30 AM, Steven Barth >>>>>> wrote: >>>>>> >>>>>>> On 03.01.2014 19:43, Dave Taht wrote: >>>>>>> >>>>>>> >>>>>>>> I was also experiencing a race condition with dnsmasq, while I had >>>>>>>> it >>>>>>>> enabling >>>>>>>> ra >>>>>>>> and >>>>>>>> dhcpv6 via dnsmasq. At the moment that's turned off by default, >>>>>>>> but >>>>>>>> I did rather prefer having dns names for my ipv6 >>>>>>>> addresses... >>>>>>> >>>>>>> >>>>>>> >>>>>>> Well 6relayd and odhcpd collect hostnames of clients acquired via >>>>>>> stateful >>>>>>> DHCPv6 and export them to dnsmasq in an additional hostfiles. At >>>>>>> least >>>>>>> that >>>>>>> seemed to work when I last tried it a few months ago. The only >>>>>>> disadvantage >>>>>>> is that there is no "ra-names" feature there. >>>>>> >>>>>> >>>>>> >>>>>> Getting to names from dhcpv4 to slaac was a neat hack and a potentia= l >>>>>> RFC. So i figure spending the time to add the same functionality int= o >>>>>> into something other than dnsmasq would be useful towards writing th= at >>>>>> rfc. >>>>>> >>>>>> >>>>>>>> is there a good way for 6re >>>>>>>> layd >>>>>>>> and dnsmasq-dhcpv6 to co-exist? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ideally they could coexist in a way that you c >>>>>>> ould >>>>>>> select dnsmasq and / >>>>>>> or >>>>>>> odhcpd for different interfaces on the same machine. odhcpd support= s >>>>>>> that >>>>>>> but dnsmasq the last time I've looked seemed to use a single socket >>>>>>> binding >>>>>>> to all interfaces for DHCP/v6 which prevents coexistance from worki= ng >>>>>>> correctly because odhcpd / 6relayd can't bind the socket after >>>>>>> dnsmasq >>>>>>> did >>>>>>> and vice versa. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Feel free to provide me with some debugging information of the >>>>>>>>> system >>>>>>>>> while >>>>>>>>> PD fails for you so I can have a look at the probable cause: >>>>>>>>> >>>>>>>>> * "ifstatus ge00" (replace ge00 with your IPv6 upstream interface= ) >>>>>>>>> * "ip addr list dev >>>>>>>>> ge01" >>>>>>>>> (replace ge01 with the interface your >>>>>>>>> downstream >>>>>>>>> router is connected) >>>>>>>>> * "ps >>>>>>>>> | grep >>>>>>>>> 6relayd" >>>>>>>>> >>>>>>>>> Anyway I will migrate all the stuff to odhcpd soon (it's successo= r >>>>>>>>> which >>>>>>>>> shares a good part of the codebase but is a bit better integrated >>>>>>>>> with >>>>>>>>> the >>>>>>>>> rest of the environment). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> same question re dnsmasq. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yeah as pointed out coexistence is a matter of binding sockets. >>>>>>> odhcpd >>>>>>> will >>>>>>> bring the functionality of dynamically enabling / disabling DHCPv4/= v6 >>>>>>> on >>>>>>> interfaces without restarting the daemon and loosing state. This is >>>>>>> one >>>>>>> of >>>>>>> the main reasons for the change and very much eases things for >>>>>>> high-level >>>>>>> protocols that do dynamic wan/lan detection. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Steven >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Regard >>>>>>>>> s, >>>>>>>>> >>>>>>>>> Steven >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 03.01.2014 18:31, Dave Taht wrote: >>>>>>>>> >>>>>>>>>> On Fri, Jan 3, 2014 at 11:50 AM, cb.list6 >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Fri, Jan 3, 2014 at 8:40 AM, Dave Taht >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> At one level I am happy to figure out this is a recently >>>>>>>>>>>> introduced >>>>>>>>>>>> bug. >>>>>>>>>>>> >>>>>>>>>>>> On the other hand I am not sure if it is 6relayd. >>>>>>>>>>>> >>>>>>>>>>>> What version of cero was working for you? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I am not entirely sure, but i think it was from September. >>>>>>>>>>> >>>>>>>>>>> CB >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> At the moment I lack the ability to d >>>>>>>>>> ebug >>>>>>>>>> the breakage in ipv6 >>>>>>>>>> dhcp-pd >>>>>>>>>> (which is odhcpd) (I am travelling). >>>>>>>>>> >>>>>>>>>> I will on my next stop next week (tuesday) setup a dhcpv6pd serv= er >>>>>>>>>> and >>>>>>>>>> see what I can see. >>>>>>>>>> >>>>>>>>>>>> On Jan 3, 2014 12:21 AM, "cb.list6" wrote= : >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I have been using CeroWRT on Comcast with a 3800 for about 6 >>>>>>>>>>>>> month. >>>>>>>>>>>>> The >>>>>>>>>>>>> DHCP-PD config has always been a little unstable for me, but >>>>>>>>>>>>> working. >>>>>>>>>>>>> >>>>>>>>>>>>> I recently upgraded to: >>>>>>>>>>>>> >>>>>>>>>>>>> root@cerowrt:/etc/config# uname -a >>>>>>>>>>>>> Linux cerowrt 3.10.24 #1 Tue Dec 24 1 >>>>>>>>>>>>> 0:50:15 >>>>>>>>>>>>> PST 2013 mips >>>>>>>>>>>>> GNU/Linux >>>>>>>>>>>>> >>>>>>>>>>>>> My WAN >>>>>>>>>>>>> gets a >>>>>>>>>>>>> /128, but i cannot get DHCP-PD to work to get >>>>>>>>>>>>> addresses >>>>>>>>>>>>> on >>>>>>>>>>>>> the rest of my interfaces. The router does seem to have good >>>>>>>>>>>>> IPv6 >>>>>>>>>>>>> access. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I fiddled with the 6relayd config and came up with this, but = it >>>>>>>>>>>>> does >>>>>>>>>>>>> not >>>>>>>>>>>>> work. Any pointers on how to get this back on track? The >>>>>>>>>>>>> result >>>>>>>>>>>>> of >>>>>>>>>>>>> the >>>>>>>>>>>>> below config is that the /128 from the WAN interfaces is now >>>>>>>>>>>>> present >>>>>>>>>>>>> on >>>>>>>>>>>>> all >>>>>>>>>>>>> the interfaces but my attached computers get no addresses. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> config server 'default' >>>>>>>>>>>>> option rd 'server' >>>>>>>>>>>>> option dhcpv6 'server' >>>>>>>>>>>>> option management_level '1' >>>>>>>>>>>>> list network 'ge01' >>>>>>>>>>>>> list network 'gw00' >>>>>>>>>>>>> list network 'gw01' >>>>>>>>>>>>> list network 'gw10' >>>>>>>>>>>>> list network 'gw11' >>>>>>>>>>>>> list network 'se00' >>>>>>>>>>>>> list network 'sw00' >>>>>>>>>>>>> list network 'sw10' >>>>>>>>>>>>> option fallback_relay 'rd dhcpv6 ndp' >>>>>>>>>>>>> option master 'ge00' >>>>>>>>>>>>> >>>>>>>>>>>>> root@cerowrt:/etc/config# un >>>>>>>>>>>>> ame >>>>>>>>>>>>> -a >>>>>>>>>>>>> >>>>>>>>>>>>> ________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Cerowrt-devel mailing list >>>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net >>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> -- >>>>>> Dave T=E4ht >>>>>> >>>>>> Fixing bufferbloat with cerowrt: >>>>>> http://www.teklibre.com/cerowrt/subscribe.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> Dave T=E4ht >>>> >>>> Fixing bufferbloat with cerowrt: >>>> http://www.teklibre.com/cerowrt/subscribe.html >>> >>> >>> >>> >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html