From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (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 54F5D21F113; Sat, 18 Jan 2014 07:46:53 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so1116327oag.35 for ; Sat, 18 Jan 2014 07:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VsBIWIhyHJd6nsxRGCabWJhRf74Gz4y3jqXn/4qBDUw=; b=KU/mzMNN7B2r1smVq8Yo2Jv52ResRaoLLi6qNv7qoy8/80biPmQEOVgflaJuYx7Frc ix7kH0+X2SvRyuhm3bHiPrHIbsY949ZTodxqlB1ecMvQsTz0vPFpYwUpyEgwjX6/KLQx yXOU/+SyIifYEZhGk5TNTFPRDV/vB+GoxOO611rJ+1V4JPtQfdYBIKI6hp2hfaOUKzHj keQQvO/CA+F5JRH6sTrzYhmk4LEWNuAUixO0qiVl6S64lgMPY/XmWQn7F3R5eOdLJh6q adoloJqm+nm5Ni3YBnIHc05uol/PWLUEUHIYMYbJNzs/z4VlCLwuiLFcaQu2ZmwzglRt yw4w== MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr7206166obb.26.1390060012289; Sat, 18 Jan 2014 07:46:52 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.150.234 with HTTP; Sat, 18 Jan 2014 07:46:52 -0800 (PST) In-Reply-To: References: Date: Sat, 18 Jan 2014 10:46:52 -0500 X-Google-Sender-Auth: URc45Mp6cM88IqXLN94Vrka0tuQ Message-ID: From: Jim Gettys To: Dave Taht Content-Type: multipart/alternative; boundary=089e013d0dc03fc89f04f040915b Cc: cerowrt@lists.bufferbloat.net, Steven Barth , "cb.list6" , "cerowrt-devel@lists.bufferbloat.net" , Matt Mathis 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:47:20 -0000 --089e013d0dc03fc89f04f040915b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jan 18, 2014 at 10:16 AM, Dave Taht wrote: > On Sat, Jan 18, 2014 at 9:46 AM, Steven Barth wrote: > > 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. > > In looking over the packet captures I don't see any dhcpv6 requests going > out 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 > client > > 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) > If renumbering is going on, I'd complain at Comcast. I'd suspect it's an artifact of an early deployment and testing rather than intentional behavior. They get to deal with service calls from anything that breaks, and this is still early days. - Jim > > > ---------- 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 > connected > >> 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 > to > >> 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 tha= t > i > >>> also switched routing from individual tables to source-constrained > routes > >>> 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). > Later > >>>>>> on 6relayd started having a race with it and seemed to be "the > >>>>>> future", so I disabled the dnsmasq version, thinking that 6relayd > was > >>>>>> 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 > our > >>>>> 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 h= ad > >>>>>>>> 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 > potential > >>>>>> RFC. So i figure spending the time to add the same functionality > into > >>>>>> into something other than dnsmasq would be useful towards writing > that > >>>>>> 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 > supports > >>>>>>> that > >>>>>>> but dnsmasq the last time I've looked seemed to use a single sock= et > >>>>>>> binding > >>>>>>> to all interfaces for DHCP/v6 which prevents coexistance from > working > >>>>>>> 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 > successor > >>>>>>>>> which > >>>>>>>>> shares a good part of the codebase but is a bit better integrat= ed > >>>>>>>>> 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 > server > >>>>>>>>>> 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, bu= t > >>>>>>>>>>>>> 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 go= od > >>>>>>>>>>>>> IPv6 > >>>>>>>>>>>>> access. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> I fiddled with the 6relayd config and came up with this, bu= t > 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 no= w > >>>>>>>>>>>>> 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 > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --089e013d0dc03fc89f04f040915b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat= , Jan 18, 2014 at 10:16 AM, Dave Taht <dave.taht@gmail.com> wrote:
On Sat, Jan 18, 2014 at 9:= 46 AM, Steven Barth <cyrus@openwrt.= org> wrote:
> That firewall reloading is due to comcast unnecessarily spamming ras e= very 3
> seconds. We already filter it down to one reload per minute. I prepare= d
> another filter yesterday which will filter out updates that dont chang= e
> anything but adress / route timers. So expect some solution for this r= eload
> spam in the coming days.

In looking over the packet captures I don't see any dhcpv6 reques= ts going out so
we are holding onto the assigned external address...

3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
=A0 =A0 inet6 2001:elided/128 scope global dynamic
=A0 =A0 =A0 =A0valid_lft 304731sec preferred_lft 304731sec
=A0 =A0 inet6 fe80:elided/64 scope link
=A0 =A0 =A0 =A0valid_lft forever preferred_lft forever

but in order to see dnsmasq advertise anything

Sat Jan 18 15:04:59 2014 d= aemon.info dnsmasq-dhcp[3318]:
RTR-ADVERT(se00) 2601:elided::

I'd had to add a static address to the interface

2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
=A0 =A0 inet6 2601:elided::2/64 scope global
=A0 =A0 =A0 =A0valid_lft forever preferred_lft forever added this manually = and
dnsmasq did router advertisements
=A0 =A0 inet6 2601:elided::1/64 scope global dynamic
=A0 =A0 =A0 =A0valid_lft 304621sec preferred_lft 304621sec # added by the d= hcpv6 client

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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
=A0 =A0 inet6 2601:elidedbutdifferent::1/64 scope global dynamic
=A0 =A0 =A0 =A0valid_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)

If renumbering is going= on, I'd complain at Comcast. =A0I'd suspect it's an artifact o= f an early deployment and testing rather than intentional behavior. =A0They= get to deal with service calls from anything that breaks, and this is stil= l early days.
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- Jim




---------- Forwarded message ----------
From: Steven Barth <cyrus@openwrt.o= rg>
Date: Sat, Jan 18, 2014 at 9:46 AM
Subject: Re: [Cerowrt-devel] 6relayd
To: Dave Taht <dave.taht@gmail.co= m>
Cc: Matt Mathis <mattmathis@goo= gle.com>, "cb.list6"
<cb.list6@gmail.com>, "= ;cerowrt-devel@lists= .bufferbloat.net"
<cerowrt-devel@li= sts.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 <dave.taht@gmail.c= om> schrieb:
>>
>> I just filed bug http://www.bufferbloat.net/issues/438 on this issue<= br> >> 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<= br> >> cerowrt 3.10.7 (?)
>>
>> we do get an external IPv6 address AND /60 dhcpv6-pd delegation fr= om
>> comcast, and distribute the /64s to each of the subnets on cero. T= he
>> 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 o= r 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 ran= ge
>> (say, whatever::2/64) dnsmasq picks it up and starts serving ipv6<= br> >> addresses. (theory: we don't have that ipv6 delegation long en= ough for
>> dnsmasq to see it before they are withdrawn)
>>
>> 3) We get plenty of instruction traps IF you delegate to the wirel= ess
>> 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<= br> >> inserted on ethernet results in no instruction traps (but there wa= s no
>> traffic either). running with with the manual ::2/64 inserted does=
>> result in routable, working, ipv6 subnet addresses that dnsmasq se= es
>> and distributes from.
>>
>> 4) tweak: ge01 needs to be added to the firewall rules for wan. ma= ybe.
>>
>> The net result is unusable native ipv6 on comcast
>> =A0. (comcast6.n= et is
>> also reporting unusable ipv6 on wireless on the xbox 1, and I don&= #39;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 endianes= s
>> problem C) we are not keeping properly track of the ipv6 address >> assignment and/or lease length. D) Comcast isn't assigning ipv= 6
>> external addresses and subnets for more than a minute. E) we have = some
>> problem on the wireless side in particular (but that seems indepen= dent
>> 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 c= onnected
>> 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 to
>> do:
>>
>> Sat Jan 18 1
>> =A03: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
>> =A0rewall
>> 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 <cyrus@openwrt.org> wrote:
>>>
>>> Fyi as stated earlier i made the switch to odhcpd yesterday. W= ith that i
>>> also switched routing from individual tables to source-constra= ined routes
>>> in
>>> the maintable.
>>>
>>> Cheers,
>>> Steven
>>>
>>>
>>>
>>>
>>> Dave Taht <dave.taht= @gmail.com> schrieb:
>>>
>>>> On Fri, Jan 17, 2014 at 1:52 AM, Matt Mathis <mattmathis@google.com>
>>>> wrote:
>>>>
>>>>> I'm final
>>>>> =A0ly
>>>>> getting back to this.
>>>>>
>>>>>> Hmm. if you uncomment everything in /etc/dnsmasq.c= onf and restart
>>>>>> dnsmasq what happens? If you have got /64s you wou= ld end up doing
>>>>>> slaac and ra announcements via dnsmasq in this cas= e.
>>>>>>
>>>>>> That was on by default before (and what was tested= in feburary). Later
>>>>>> on 6relayd started having a race with it and seeme= d to be "the
>>>>>> future", so I disabled the dnsmasq version, t= hinking that 6relayd was
>>>>>> the answer. It's entirely possible that's<= br> >>>>>> merely configured wrong.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Now I get global /64's on my LAN interfaces, but I= am still not
>>>>> answering
>>>>> dh
>>>>> cp6 for
>>>>> attached hosts. =A0I retried both version of the 6rela= yd init
>>>>> script....
>>>>>
>>>>> dnsmasq.conf contains:
>>>>> enable-ra
>>>>> dhcp-range=3D::1,::400,constructor:se00,ra-names,ra-st= ateless
>>>>> dhcp-range=3D::1,::400,constructor:sw00,ra-names,ra-st= ateless
>>>>> dhcp-range=3D::1,::400,constructor:gw00,ra-names,ra-st= ateless
>>>>> dhcp-range=3D::1,::400,constructor:sw10,ra-names,ra-st= ateless
>>>>> dhcp-range=3D::1,::400,constructor:gw10,ra-names,ra-st= ateless
>>>>>
>>>>>
>>>>> I am running: Linux cerowrt 3.10.24 #1 Tue Dec 24 10:5= 0:15 PST
>>>>> 2013.....
>>>>> which might be just a bit too fresh.... =A0Would you s= uggest another?
>>>>
>>>>
>>>>
>>>> You are not getting slaac either?
>>>>
>>>> An ifconfig on an interface and a packet dump of ipv6 pack= ets would be
>>>> helpful.
>>>>
>>>>> I have a spare 3700, so I think I will try some altern= ate vintages.
>>>>>
>>>>> Thanks,
>>>>> --MM--
>>>>> The
>>>>> best way to predict the future is to create it. =A0- A= lan Kay
>>>>>
>>>>>
>>>>> Privacy matters! =A0We know from recent events that pe= ople are using our
>>>>> services to speak in
>>>>> defiance of unjust governments. =A0 We treat privacy >>>>> and
>>>>> security as matters of life and death, because for som= e users, they
>>>>> are.
>>>>>
>>>>>
>>>>> On Sun, Jan 5, 2014 at 7:48 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Jan 4, 2014 at 1:30 AM, Steven Barth <<= a href=3D"mailto:cyrus@openwrt.org">cyrus@openwrt.org>
>>>>>> wrote:
>>>>>>
>>>>>>> On 03.01.2014 19:43, Dave Taht wrote:
>>>>>>>
>>>>>>>
>>>>>>>> I was also experiencing a race condition w= ith 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 m= y ipv6
>>>>>>>> addresses...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Well 6relayd and odhcpd collect hostnames of c= lients acquired via
>>>>>>> stateful
>>>>>>> DHCPv6 and export them to dnsmasq in an additi= onal hostfiles. At
>>>>>>> least
>>>>>>> that
>>>>>>> seemed to work when I last tried it a few mont= hs ago. The only
>>>>>>> disadvantage
>>>>>>> is that there is no "ra-names" featu= re there.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Getting to names from dhcpv4 to slaac was a neat h= ack and a potential
>>>>>> RFC. So i figure spending the time to add the same= functionality into
>>>>>> into something other than dnsmasq would be useful = towards writing that
>>>>>> 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=
>>>>>>> =A0ould
>>>>>>> select dnsmasq and /
>>>>>>> or
>>>>>>> odhcpd for different interfaces on the same ma= chine. odhcpd supports
>>>>>>> that
>>>>>>> but dnsmasq the last time I've looked seem= ed to use a single socket
>>>>>>> binding
>>>>>>> to all interfaces for DHCP/v6 which prevents c= oexistance from working
>>>>>>> correctly because odhcpd / 6relayd can't b= ind the socket after
>>>>>>> dnsmasq
>>>>>>> did
>>>>>>> and vice versa.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> Feel free to provide me with some debu= gging information of the
>>>>>>>>> system
>>>>>>>>> while
>>>>>>>>> PD fails for you so I can have a look = at the probable cause:
>>>>>>>>>
>>>>>>>>> * "ifstatus ge00" (replace g= e00 with your IPv6 upstream interface)
>>>>>>>>> * "ip addr list dev
>>>>>>>>> ge01"
>>>>>>>>> (replace ge01 with the interface your<= br> >>>>>>>>> downstream
>>>>>>>>> router is connected)
>>>>>>>>> * "ps
>>>>>>>>> =A0| grep
>>>>>>>>> 6relayd"
>>>>>>>>>
>>>>>>>>> Anyway I will migrate all the stuff to= odhcpd soon (it's successor
>>>>>>>>> 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 enablin= g / disabling DHCPv4/v6
>>>>>>> on
>>>>>>> interfaces without restarting the daemon and l= oosing 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
>>>>>>>>> =A0s,
>>>>>>>>>
>>>>>>>>> Steven
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03.01.2014 18:31, Dave Taht wrote:<= br> >>>>>>>>>
>>>>>>>>>> On Fri, Jan 3, 2014 at 11:50 AM, c= b.list6 <cb.list6@gmail.com>= ;
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 3, 2014 at 8:40 AM= , Dave Taht <dave.taht@gmail.com<= /a>>
>>>>>>>>>>> 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 w= orking for you?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I am not entirely sure, but i = think it was from September.
>>>>>>>>>>>
>>>>>>>>>>> CB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> At the moment I lack the ability t= o d
>>>>>>>>>> =A0ebug
>>>>>>>>>> the breakage in ipv6
>>>>>>>>>> dhcp-pd
>>>>>>>>>> (which is odhcpd) (I am travelling= ).
>>>>>>>>>>
>>>>>>>>>> I will on my next stop next week (= tuesday) setup a dhcpv6pd server
>>>>>>>>>> and
>>>>>>>>>> see what I can see.
>>>>>>>>>>
>>>>>>>>>>>> On Jan 3, 2014 12:21 AM, &= quot;cb.list6" <cb.list6@gmai= l.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have been using Cero= WRT on Comcast with a 3800 for about 6
>>>>>>>>>>>>> month.
>>>>>>>>>>>>> The
>>>>>>>>>>>>> DHCP-PD config has alw= ays been a little unstable for me, but
>>>>>>>>>>>>> working.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I recently upgraded to= :
>>>>>>>>>>>>>
>>>>>>>>>>>>> root@cerowrt:/etc/conf= ig# uname -a
>>>>>>>>>>>>> Linux cerowrt 3.10.24 = #1 Tue Dec 24 1
>>>>>>>>>>>>> 0:50:15
>>>>>>>>>>>>> PST 2013 mips
>>>>>>>>>>>>> GNU/Linux
>>>>>>>>>>>>>
>>>>>>>>>>>>> My WAN
>>>>>>>>>>>>> =A0 gets a
>>>>>>>>>>>>> /128, but i cannot get= DHCP-PD to work to get
>>>>>>>>>>>>> addresses
>>>>>>>>>>>>> on
>>>>>>>>>>>>> the rest of my interfa= ces. =A0The router does seem to have good
>>>>>>>>>>>>> IPv6
>>>>>>>>>>>>> access.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I fiddled with the 6re= layd config and came up with this, but it
>>>>>>>>>>>>> does
>>>>>>>>>>>>> not
>>>>>>>>>>>>> work. =A0Any pointers = on how to get this back on track? =A0The
>>>>>>>>>>>>> result
>>>>>>>>>>>>> of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> below config is that t= he /128 from the WAN interfaces is now
>>>>>>>>>>>>> present
>>>>>>>>>>>>> on
>>>>>>>>>>>>> all
>>>>>>>>>>>>> the interfaces but my = attached computers get no addresses.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> config server 'def= ault'
>>>>>>>>>>>>> option rd 'server&= #39;
>>>>>>>>>>>>> option dhcpv6 'ser= ver'
>>>>>>>>>>>>> option management_leve= l '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 'ge0= 0'
>>>>>>>>>>>>>
>>>>>>>>>>>>> root@cerowrt:/etc/conf= ig# 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



--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.= bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

--089e013d0dc03fc89f04f040915b--