I am painfully aware that a change in comcast's deployment starting in late december started messing up older versions of cerowrt, openwrt, etc.
(short version, they started announcing ras every three seconds, which triggers a reload/reconfiguration of openwrt that takes longer than 3 seconds...) The openwrt folk fixed it upstream a few weeks back and the last couple development releases of cero have the fixes. (ghu help those that are merely ipv6 certified and not paying attention) https://lists.bufferbloat.net/pipermail/cerowrt-devel/2014-January/002093.html I have since produced several comcast specific releases. This one is pretty stable http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.28-4/ I recomend all comcast users on cerowrt upgrade ASAP as comcast is aggressively turning on ipv6 everywhere. (and it's pretty wonderful when it works) Note that you should make a backup, reflash from scratch, and re-apply your mods via the gui as much as changed since 3.8. I usually take a backup via scp [email protected]:/overlay and then look hard at the modified files in /etc and /etc/config As this is still a dev release it has some problems, notably HT40+ mode seems to be borked on 5ghz. Also I am discovering that providers deploying ipv6 (AT&T, now possibly comcast) seem to be (inadvertently) disabling various forms of tunnelling. I still haven't got he to work again simultaneously with native ipv6 on comcast. (but unlike the first comcast-specific release, trying to enable one doesn't blow up the router) Another option for you is to disable the dhcp-pd request on your current version so you don't get native ipv6... I hope to resume marching towards a final stable release over the coming weeks. In the interim, on comcast, upgrade ASAP. On Sat, Feb 1, 2014 at 5:29 AM, Chuck Anderson <[email protected]> wrote: > This morning my Linux PC which has a direct connection to my Comcast > cable modem (no router in between) lost its IPv4 address. During > troubleshooting, I noticed that the dhclient was unable to get an IPv4 > address from Comcast. I ran tcpdump and discovered that the CeroWRT > router, also connected to the same cable modem via a switch, was > flooding the WAN with DHCPv6 SOLICIT packets with about 4700 > packets/sec, 6.6 megabits/sec of traffic! I immediately unplugged > CeroWRT from the WAN and then my PC was able to get an IPv4 address > from Comcast. > > I know CeroWrt 3.7.5-2 is old at this point, but I'm wondering if > something else changed to cause this behavior. Maybe Comcast > IPv6-enabled my CMTS finally? I've been using HE tunnels for IPv6, > one on a Linksys OpenWRT for my "production" network and a separate > tunnel on this CeroWRT for "testing". > > There is one other change that was made to my Linux PC--I booted into > a new kernel yesterday morning and had a similar problem with the > inability to get an IPv4 address via DHCP from Comcast for about 30 > minutes, then it just started working on its own. (I hadn't noticed > initially since I was using IPv6 to get where I needed to go.) I > didn't have time to troubleshoot it at the time, but I assumed it was > due to this IPv6 change in the Fedora kernel: > > * Wed Jan 29 2014 Justin M. Forbes <[email protected]> - 3.12.9-201 > - ipv6 addrconf: revert /proc/net/if_inet6 ifa_flag format (rhbz 1056711) > > * Tue Jan 28 2014 Josh Boyer <[email protected]> > - Add patch from Stanislaw Gruszka to fix ath9k BUG (rhbz 990955) > > * Mon Jan 27 2014 Justin M. Forbes <[email protected]> - 3.12.9-200 > - Backport new IPv6 address flag IFA_F_NOPREFIXROUTE and IFA_F_MANAGETEMPADDR > (rhbz 1056711) > - Linux v3.12.9 > - i915: remove pm_qos request on error (rhbz 1057533) > > See https://bugzilla.redhat.com/show_bug.cgi?id=1056711 for details > about that. > > Each time this loss of IPv4 happened, I noticed the NIC link went down > right before it started. Maybe the flooding was happening yesterday > morning too, and the flooding caused my poor 5-port Netgear switch to > flake out and flap the NIC links? Alternatively, maybe the link flap > itself was what caused odhcp6c to wig out and start flooding in the > first place? Unfortunately I don't have a tcpdump from yesterday > morning to confirm this. > > CeroWRT status: > > Router Name cerowrt > Router Model NETGEAR WNDR3700v2 > Firmware Version CeroWrt Modena 3.7.5-2 / LuCI Trunk (trunk+svn) > Kernel Version 3.7.5 > Local Time Sat Feb 1 07:54:43 2014 > Uptime 58d 6h 56m 51s > > The DHCPv6 client is odhcp6c: > > root@cerowrt:~# ps |grep dhc > 980 root 1720 S udhcpc -p /var/run/udhcpc-ge00.pid -s /lib/netifd/dh > 1335 root 804 R odhcp6c -s /lib/netifd/dhcpv6.script -Ntry -P60 ge00 > 3725 root 1704 S grep dhc > > Here is an example packet from the DHCPv6 flood: > > No. Time Source Destination Protocol > Length Info > 1 0.000000 fe80::c63d:c7ff:feb0:8f41 ff02::1:2 DHCPv6 > 179 Solicit XID: 0x45eb91 CID: 00030001c43dc7b08f41 > > Frame 1: 179 bytes on wire (1432 bits), 179 bytes captured (1432 bits) > Encapsulation type: Ethernet (1) > Arrival Time: Feb 1, 2014 07:20:27.723633000 EST > [Time shift for this packet: 0.000000000 seconds] > Epoch Time: 1391257227.723633000 seconds > [Time delta from previous captured frame: 0.000000000 seconds] > [Time delta from previous displayed frame: 0.000000000 seconds] > [Time since reference or first frame: 0.000000000 seconds] > Frame Number: 1 > Frame Length: 179 bytes (1432 bits) > Capture Length: 179 bytes (1432 bits) > [Frame is marked: False] > [Frame is ignored: False] > [Protocols in frame: eth:ipv6:udp:dhcpv6] > [Coloring Rule Name: UDP] > [Coloring Rule String: udp] > Ethernet II, Src: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41), Dst: > IPv6mcast_00:01:00:02 (33:33:00:01:00:02) > Destination: IPv6mcast_00:01:00:02 (33:33:00:01:00:02) > Address: IPv6mcast_00:01:00:02 (33:33:00:01:00:02) > .... ..1. .... .... .... .... = LG bit: Locally administered address > (this is NOT the factory default) > .... ...1 .... .... .... .... = IG bit: Group address > (multicast/broadcast) > Source: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41) > Address: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > .... ...0 .... .... .... .... = IG bit: Individual address (unicast) > Type: IPv6 (0x86dd) > Internet Protocol Version 6, Src: fe80::c63d:c7ff:feb0:8f41 > (fe80::c63d:c7ff:feb0:8f41), Dst: ff02::1:2 (ff02::1:2) > 0110 .... = Version: 6 > [0110 .... = This field makes the filter "ip.version == 6" possible: > 6] > .... 0000 0000 .... .... .... .... .... = Traffic class: 0x00000000 > .... 0000 00.. .... .... .... .... .... = Differentiated Services > Field: Default (0x00000000) > .... .... ..0. .... .... .... .... .... = ECN-Capable Transport > (ECT): Not set > .... .... ...0 .... .... .... .... .... = ECN-CE: Not set > .... .... .... 0000 0000 0000 0000 0000 = Flowlabel: 0x00000000 > Payload length: 125 > Next header: UDP (17) > Hop limit: 1 > Source: fe80::c63d:c7ff:feb0:8f41 (fe80::c63d:c7ff:feb0:8f41) > [Source SA MAC: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41)] > Destination: ff02::1:2 (ff02::1:2) > [Source GeoIP: Unknown] > [Destination GeoIP: Unknown] > User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: > dhcpv6-server (547) > Source port: dhcpv6-client (546) > Destination port: dhcpv6-server (547) > Length: 125 > Checksum: 0xda1c [validation disabled] > [Good Checksum: False] > [Bad Checksum: False] > DHCPv6 > Message type: Solicit (1) > Transaction ID: 0x45eb91 > Elapsed time > Option: Elapsed time (8) > Length: 2 > Value: ffff > Elapsed-time: 655350 ms > Option Request > Option: Option Request (6) > Length: 10 > Value: 00170018003800160015 > Requested Option code: DNS recursive name server (23) > Requested Option code: Domain Search List (24) > Requested Option code: Unknown (56) > Requested Option code: SIP Servers IPv6 Address List (22) > Requested Option code: SIP Server Domain Name List (21) > Client Identifier > Option: Client Identifier (1) > Length: 10 > Value: 00030001c43dc7b08f41 > DUID: 00030001c43dc7b08f41 > DUID Type: link-layer address (3) > Hardware type: Ethernet (1) > Link-layer address: c4:3d:c7:b0:8f:41 > Reconfigure Accept > Option: Reconfigure Accept (20) > Length: 0 > Fully Qualified Domain Name > Option: Fully Qualified Domain Name (39) > Length: 10 > Value: 00076365726f77727400 > 0000 0... = Reserved: 0x00 > .... .0.. = N bit: Server should perform DNS updates > .... ..0. = O bit: Server has not overridden client's S bit preference > .... ...0 = S bit: Server should not perform forward DNS updates > Domain: cerowrt > Identity Association for Non-temporary Address > Option: Identity Association for Non-temporary Address (3) > Length: 12 > Value: 000000010000000000000000 > IAID: 00000001 > T1: 0 > T2: 0 > Identity Association for Prefix Delegation > Option: Identity Association for Prefix Delegation (25) > Length: 41 > Value: 000000010000000000000000001a00190000000000000000... > IAID: 00000001 > T1: 0 > T2: 0 > IA Prefix > Option: IA Prefix (26) > Length: 25 > Value: 00000000000000003c000000000000000000000000000000... > Preferred lifetime: 0 > Valid lifetime: 0 > Prefix length: 60 > Prefix address: :: (::) > > 0000 33 33 00 01 00 02 c4 3d c7 b0 8f 41 86 dd 60 00 33.....=...A..`. > 0010 00 00 00 7d 11 01 fe 80 00 00 00 00 00 00 c6 3d ...}...........= > 0020 c7 ff fe b0 8f 41 ff 02 00 00 00 00 00 00 00 00 .....A.......... > 0030 00 00 00 01 00 02 02 22 02 23 00 7d da 1c 01 45 .......".#.}...E > 0040 eb 91 00 08 00 02 ff ff 00 06 00 0a 00 17 00 18 ................ > 0050 00 38 00 16 00 15 00 01 00 0a 00 03 00 01 c4 3d .8.............= > 0060 c7 b0 8f 41 00 14 00 00 00 27 00 0a 00 07 63 65 ...A.....'....ce > 0070 72 6f 77 72 74 00 00 03 00 0c 00 00 00 01 00 00 rowrt........... > 0080 00 00 00 00 00 00 00 19 00 29 00 00 00 01 00 00 .........)...... > 0090 00 00 00 00 00 00 00 1a 00 19 00 00 00 00 00 00 ................ > 00a0 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 ..<............. > 00b0 00 00 00 ... > > The CeroWRT system log is attached. Nothing looks strange except the > loss of ge00 link around 6:24 this morning, which is right around when > I lost IPv4 connectivity to my Linux PC (I have a system monitoring > this IP and it SMS's me if it goes down). My PC's NIC link went down > at exactly the same time. At 7:24 is when I unplugged CeroWRT. > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
