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