On Sat, Jan 18, 2014 at 9:46 AM, Steven Barth <cy...@openwrt.org> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 <cy...@openwrt.org>
Date: Sat, Jan 18, 2014 at 9:46 AM
Subject: Re: [Cerowrt-devel] 6relayd
To: Dave Taht <dave.t...@gmail.com>
Cc: Matt Mathis <mattmat...@google.com>, "cb.list6"
<cb.li...@gmail.com>, "cerowrt-devel@lists.bufferbloat.net"
<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 <dave.t...@gmail.com> 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 <cy...@openwrt.org> wrote:
>>>
>>> Fyi as stated earlier i made the switch to odhcpd yesterday. With that i
>>> also switched routing from individual tables to source-constrained routes
>>> in
>>> the maintable.
>>>
>>> Cheers,
>>> Steven
>>>
>>>
>>>
>>>
>>> Dave Taht <dave.t...@gmail.com> schrieb:
>>>
>>>> On Fri, Jan 17, 2014 at 1:52 AM, Matt Mathis <mattmat...@google.com>
>>>> 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=::1,::400,constructor:se00,ra-names,ra-stateless
>>>>> dhcp-range=::1,::400,constructor:sw00,ra-names,ra-stateless
>>>>> dhcp-range=::1,::400,constructor:gw00,ra-names,ra-stateless
>>>>> dhcp-range=::1,::400,constructor:sw10,ra-names,ra-stateless
>>>>> dhcp-range=::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 <dave.t...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, Jan 4, 2014 at 1:30 AM, Steven Barth <cy...@openwrt.org>
>>>>>> 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 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 socket
>>>>>>> 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 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 <cb.li...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Fri, Jan 3, 2014 at 8:40 AM, Dave Taht <dave.t...@gmail.com>
>>>>>>>>>>> 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" <cb.li...@gmail.com> 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äht
>>>>>>
>>>>>> Fixing bufferbloat with cerowrt:
>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Dave Täht
>>>>
>>>> Fixing bufferbloat with cerowrt:
>>>> http://www.teklibre.com/cerowrt/subscribe.html
>>>
>>>
>>>
>>>
>> --
>> Dave Täht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
--
Dave Täht
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
