From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (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 00F3D201B88 for ; Sat, 1 Feb 2014 11:33:18 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so6690097oah.31 for ; Sat, 01 Feb 2014 11:33:18 -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=TtkOX4FjECzFgRwOeqxGgEY7k7Gz3//K1dCSPfqSahE=; b=0Ln5p6Oix5ibLg0FsApbJYrJGptTY0An9BjZKEGaJ1RRf+eA1TpvIiQ/xE26HJK9e8 TyHqxtMSbst2qEtD/TxnhkQA/mZ36atR8VVsdeIINDdemlPcY6PopAuhSh3o+OqKAkWe kgwBlySg2bblxiYq2N9dtb0nK36DNaTnuVSvmxLVFtDdcxiWsjbNIwvc8LN3SGZDMljh qMRTzo+I5jpUfKJj9yrlkFR7Zo9vbxuNu6umuzXoumQcd/cuvE+XguooyB4je136yBq+ mGY/YxXUrji9UcJkjhc+VO0JenDTKlAh69C/5Lx2u9dmJgjNJnw7AQgOEhS8GmUxJjA5 R5cw== MIME-Version: 1.0 X-Received: by 10.182.24.69 with SMTP id s5mr22845971obf.35.1391283197685; Sat, 01 Feb 2014 11:33:17 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.84.162 with HTTP; Sat, 1 Feb 2014 11:33:17 -0800 (PST) In-Reply-To: References: <20140201132948.GU15505@angus.ind.WPI.EDU> Date: Sat, 1 Feb 2014 14:33:17 -0500 X-Google-Sender-Auth: j4ur5DchrJNgmpEL8TaXgwQfxt0 Message-ID: From: Jim Gettys To: Dave Taht Content-Type: multipart/alternative; boundary=001a11c2a20cc7ba9b04f15d5c70 Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] odhcp6c went crazy flooding Comcast with DHCPv6 SOLICITs 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, 01 Feb 2014 19:33:19 -0000 --001a11c2a20cc7ba9b04f15d5c70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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). So as Dave says, very large areas of Comcast's networks are going live for native IPv6 now. http://corporate.comcast.com/comcast-voices/comcasts-xfinity-internet-now-t= he-worlds-largest-native-ipv6-deployment - Jim On Sat, Feb 1, 2014 at 11:43 AM, Dave Taht wrote: > 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 root@gw.home.lan:/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 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 - > 3.12.9-201 > > - ipv6 addrconf: revert /proc/net/if_inet6 ifa_flag format (rhbz 105671= 1) > > > > * Tue Jan 28 2014 Josh Boyer > > - Add patch from Stanislaw Gruszka to fix ath9k BUG (rhbz 990955) > > > > * Mon Jan 27 2014 Justin M. Forbes - > 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=3D1056711 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 Protoco= l > 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. .... .... .... .... =3D LG bit: Locally administered > address (this is NOT the factory default) > > .... ...1 .... .... .... .... =3D 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. .... .... .... .... =3D LG bit: Globally unique addre= ss > (factory default) > > .... ...0 .... .... .... .... =3D 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 .... =3D Version: 6 > > [0110 .... =3D This field makes the filter "ip.version =3D=3D 6= " > possible: 6] > > .... 0000 0000 .... .... .... .... .... =3D Traffic class: 0x000000= 00 > > .... 0000 00.. .... .... .... .... .... =3D Differentiated > Services Field: Default (0x00000000) > > .... .... ..0. .... .... .... .... .... =3D ECN-Capable Transpo= rt > (ECT): Not set > > .... .... ...0 .... .... .... .... .... =3D ECN-CE: Not set > > .... .... .... 0000 0000 0000 0000 0000 =3D 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... =3D Reserved: 0x00 > > .... .0.. =3D N bit: Server should perform DNS updates > > .... ..0. =3D O bit: Server has not overridden client's S bit > preference > > .... ...0 =3D S bit: Server should not perform forward DNS upda= tes > > 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.....=3D...A.= .`. > > 0010 00 00 00 7d 11 01 fe 80 00 00 00 00 00 00 c6 3d ...}...........= =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.............= =3D > > 0060 c7 b0 8f 41 00 14 00 00 00 27 00 0a 00 07 63 65 ...A.....'....c= e > > 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 > > 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 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --001a11c2a20cc7ba9b04f15d5c70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I w= ill note when I talked to John=A0Brzozowski=A0last summer about when IPv6 w= ould appear in the Boston area, he said it would be soon; the hold up was n= o 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).

So as Dave says, very large ar= eas of Comcast's networks are going live for native IPv6 now.

http://corporate.comcast.com/comcast-voices/comcasts-xfini= ty-internet-now-the-worlds-largest-native-ipv6-deployment
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 - Jim


<= div class=3D"gmail_extra">

On Sat, Feb 1, 2014 at 11:43 AM, Dave Taht <dave.taht@gmail.com><= /span> wrote:
I am painfully aware that a change in comcast's deployment starting in<= br> 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/c= erowrt-devel/2014-January/002093.html

I have since produced several comcast specific releases. This one is
pretty stable

http://snapon.lab.bufferbloat.net/~cero2/cerowr= t/wndr/comcast/3.10.28-4/

I recomend all comcast users on cerowrt upgrade ASAP as comcast is aggressi= vely
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 root@gw.home.lan:/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 <cra@wpi.edu> wrote:
> This morning my Linux PC which has a direct connection to my Comcast > cable modem (no router in between) lost its IPv4 address. =A0During > troubleshooting, I noticed that the dhclient was unable to get an IPv4=
> address from Comcast. =A0I 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! =A0I 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<= br> > something else changed to cause this behavior. =A0Maybe Comcast
> IPv6-enabled my CMTS finally? =A0I've been using HE tunnels for IP= v6,
> one on a Linksys OpenWRT for my "production" network and a s= eparate
> tunnel on this CeroWRT for "testing".
>
> 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
> inability to get an IPv4 address via DHCP from Comcast for about 30 > minutes, then it just started working on its own. =A0(I hadn't not= iced
> initially since I was using IPv6 to get where I needed to go.) =A0I > 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 <jforbes@fedoraproject.org> - 3.12.9-201
> - ipv6 addrconf: revert /proc/net/if_inet6 ifa_flag format (rhbz 10567= 11)
>
> * Tue Jan 28 2014 Josh Boyer <jwboyer@fedoraproject.org>
> - Add patch from Stanislaw Gruszka to fix ath9k BUG (rhbz 990955)
>
> * Mon Jan 27 2014 Justin M. Forbes <jforbes@fedoraproject.org> - 3.12.9-200
> - Backport new IPv6 address flag IFA_F_NOPREFIXROUTE and IFA_F_MANAGET= EMPADDR (rhbz 1056711)
> - Linux v3.12.9
> - i915: remove pm_qos request on error (rhbz 1057533)
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=3D1056711= for details
> about that.
>
> Each time this loss of IPv4 happened, I noticed the NIC link went down=
> right before it started. =A0Maybe the flooding was happening yesterday=
> morning too, and the flooding caused my poor 5-port Netgear switch to<= br> > flake out and flap the NIC links? =A0Alternatively, maybe the link fla= p
> itself was what caused odhcp6c to wig out and start flooding in the > first place? =A0Unfortunately I don't have a tcpdump from yesterda= y
> morning to confirm this.
>
> CeroWRT status:
>
> Router Name =A0cerowrt
> Router Model NETGEAR WNDR3700v2
> Firmware Version =A0 =A0 CeroWrt Modena 3.7.5-2 / LuCI Trunk (trunk+sv= n)
> Kernel Version =A0 =A0 =A0 3.7.5
> Local Time =A0 =A0 =A0 =A0 =A0 Sat Feb 1 07:54:43 2014
> Uptime =A0 =A0 =A0 =A0 =A0 =A0 =A0 58d 6h 56m 51s
>
> The DHCPv6 client is odhcp6c:
>
> root@cerowrt:~# ps |grep dhc
> =A0 980 root =A0 =A0 =A01720 S =A0 =A0udhcpc -p /var/run/udhcpc-ge00.p= id -s /lib/netifd/dh
> =A01335 root =A0 =A0 =A0 804 R =A0 =A0odhcp6c -s /lib/netifd/dhcpv6.sc= ript -Ntry -P60 ge00
> =A03725 root =A0 =A0 =A01704 S =A0 =A0grep dhc
>
> Here is an example packet from the DHCPv6 flood:
>
> No. =A0 =A0 Time =A0 =A0 =A0 =A0Source =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Destination =A0 =A0 =A0 =A0 =A0 Protocol Length Info
> =A0 =A0 =A0 1 0.000000 =A0 =A0fe80::c63d:c7ff:feb0:8f41 ff02::1:2 =A0 = =A0 =A0 =A0 =A0 =A0 DHCPv6 =A0 179 =A0 =A0Solicit XID: 0x45eb91 CID: 000300= 01c43dc7b08f41
>
> Frame 1: 179 bytes on wire (1432 bits), 179 bytes captured (1432 bits)=
> =A0 =A0 Encapsulation type: Ethernet (1)
> =A0 =A0 Arrival Time: Feb =A01, 2014 07:20:27.723633000 EST
> =A0 =A0 [Time shift for this packet: 0.000000000 seconds]
> =A0 =A0 Epoch Time: 1391257227.723633000 seconds
> =A0 =A0 [Time delta from previous captured frame: 0.000000000 seconds]=
> =A0 =A0 [Time delta from previous displayed frame: 0.000000000 seconds= ]
> =A0 =A0 [Time since reference or first frame: 0.000000000 seconds]
> =A0 =A0 Frame Number: 1
> =A0 =A0 Frame Length: 179 bytes (1432 bits)
> =A0 =A0 Capture Length: 179 bytes (1432 bits)
> =A0 =A0 [Frame is marked: False]
> =A0 =A0 [Frame is ignored: False]
> =A0 =A0 [Protocols in frame: eth:ipv6:udp:dhcpv6]
> =A0 =A0 [Coloring Rule Name: UDP]
> =A0 =A0 [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)
> =A0 =A0 Destination: IPv6mcast_00:01:00:02 (33:33:00:01:00:02)
> =A0 =A0 =A0 =A0 Address: IPv6mcast_00:01:00:02 (33:33:00:01:00:02)
> =A0 =A0 =A0 =A0 .... ..1. .... .... .... .... =3D LG bit: Locally admi= nistered address (this is NOT the factory default)
> =A0 =A0 =A0 =A0 .... ...1 .... .... .... .... =3D IG bit: Group addres= s (multicast/broadcast)
> =A0 =A0 Source: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41)
> =A0 =A0 =A0 =A0 Address: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41)
> =A0 =A0 =A0 =A0 .... ..0. .... .... .... .... =3D LG bit: Globally uni= que address (factory default)
> =A0 =A0 =A0 =A0 .... ...0 .... .... .... .... =3D IG bit: Individual a= ddress (unicast)
> =A0 =A0 Type: IPv6 (0x86dd)
> Internet Protocol Version 6, Src: fe80::c63d:c7ff:feb0:8f41 (fe80::c63= d:c7ff:feb0:8f41), Dst: ff02::1:2 (ff02::1:2)
> =A0 =A0 0110 .... =3D Version: 6
> =A0 =A0 =A0 =A0 [0110 .... =3D This field makes the filter "ip.ve= rsion =3D=3D 6" possible: 6]
> =A0 =A0 .... 0000 0000 .... .... .... .... .... =3D Traffic class: 0x0= 0000000
> =A0 =A0 =A0 =A0 .... 0000 00.. .... .... .... .... .... =3D Differenti= ated Services Field: Default (0x00000000)
> =A0 =A0 =A0 =A0 .... .... ..0. .... .... .... .... .... =3D ECN-Capabl= e Transport (ECT): Not set
> =A0 =A0 =A0 =A0 .... .... ...0 .... .... .... .... .... =3D ECN-CE: No= t set
> =A0 =A0 .... .... .... 0000 0000 0000 0000 0000 =3D Flowlabel: 0x00000= 000
> =A0 =A0 Payload length: 125
> =A0 =A0 Next header: UDP (17)
> =A0 =A0 Hop limit: 1
> =A0 =A0 Source: fe80::c63d:c7ff:feb0:8f41 (fe80::c63d:c7ff:feb0:8f41)<= br> > =A0 =A0 [Source SA MAC: Netgear_b0:8f:41 (c4:3d:c7:b0:8f:41)]
> =A0 =A0 Destination: ff02::1:2 (ff02::1:2)
> =A0 =A0 [Source GeoIP: Unknown]
> =A0 =A0 [Destination GeoIP: Unknown]
> User Datagram Protocol, Src Port: dhcpv6-client (546), Dst Port: dhcpv= 6-server (547)
> =A0 =A0 Source port: dhcpv6-client (546)
> =A0 =A0 Destination port: dhcpv6-server (547)
> =A0 =A0 Length: 125
> =A0 =A0 Checksum: 0xda1c [validation disabled]
> =A0 =A0 =A0 =A0 [Good Checksum: False]
> =A0 =A0 =A0 =A0 [Bad Checksum: False]
> DHCPv6
> =A0 =A0 Message type: Solicit (1)
> =A0 =A0 Transaction ID: 0x45eb91
> =A0 =A0 Elapsed time
> =A0 =A0 =A0 =A0 Option: Elapsed time (8)
> =A0 =A0 =A0 =A0 Length: 2
> =A0 =A0 =A0 =A0 Value: ffff
> =A0 =A0 =A0 =A0 Elapsed-time: 655350 ms
> =A0 =A0 Option Request
> =A0 =A0 =A0 =A0 Option: Option Request (6)
> =A0 =A0 =A0 =A0 Length: 10
> =A0 =A0 =A0 =A0 Value: 00170018003800160015
> =A0 =A0 =A0 =A0 Requested Option code: DNS recursive name server (23)<= br> > =A0 =A0 =A0 =A0 Requested Option code: Domain Search List (24)
> =A0 =A0 =A0 =A0 Requested Option code: Unknown (56)
> =A0 =A0 =A0 =A0 Requested Option code: SIP Servers IPv6 Address List (= 22)
> =A0 =A0 =A0 =A0 Requested Option code: SIP Server Domain Name List (21= )
> =A0 =A0 Client Identifier
> =A0 =A0 =A0 =A0 Option: Client Identifier (1)
> =A0 =A0 =A0 =A0 Length: 10
> =A0 =A0 =A0 =A0 Value: 00030001c43dc7b08f41
> =A0 =A0 =A0 =A0 DUID: 00030001c43dc7b08f41
> =A0 =A0 =A0 =A0 DUID Type: link-layer address (3)
> =A0 =A0 =A0 =A0 Hardware type: Ethernet (1)
> =A0 =A0 =A0 =A0 Link-layer address: c4:3d:c7:b0:8f:41
> =A0 =A0 Reconfigure Accept
> =A0 =A0 =A0 =A0 Option: Reconfigure Accept (20)
> =A0 =A0 =A0 =A0 Length: 0
> =A0 =A0 Fully Qualified Domain Name
> =A0 =A0 =A0 =A0 Option: Fully Qualified Domain Name (39)
> =A0 =A0 =A0 =A0 Length: 10
> =A0 =A0 =A0 =A0 Value: 00076365726f77727400
> =A0 =A0 =A0 =A0 0000 0... =3D Reserved: 0x00
> =A0 =A0 =A0 =A0 .... .0.. =3D N bit: Server should perform DNS updates=
> =A0 =A0 =A0 =A0 .... ..0. =3D O bit: Server has not overridden client&= #39;s S bit preference
> =A0 =A0 =A0 =A0 .... ...0 =3D S bit: Server should not perform forward= DNS updates
> =A0 =A0 =A0 =A0 Domain: cerowrt
> =A0 =A0 Identity Association for Non-temporary Address
> =A0 =A0 =A0 =A0 Option: Identity Association for Non-temporary Address= (3)
> =A0 =A0 =A0 =A0 Length: 12
> =A0 =A0 =A0 =A0 Value: 000000010000000000000000
> =A0 =A0 =A0 =A0 IAID: 00000001
> =A0 =A0 =A0 =A0 T1: 0
> =A0 =A0 =A0 =A0 T2: 0
> =A0 =A0 Identity Association for Prefix Delegation
> =A0 =A0 =A0 =A0 Option: Identity Association for Prefix Delegation (25= )
> =A0 =A0 =A0 =A0 Length: 41
> =A0 =A0 =A0 =A0 Value: 000000010000000000000000001a0019000000000000000= 0...
> =A0 =A0 =A0 =A0 IAID: 00000001
> =A0 =A0 =A0 =A0 T1: 0
> =A0 =A0 =A0 =A0 T2: 0
> =A0 =A0 =A0 =A0 IA Prefix
> =A0 =A0 =A0 =A0 =A0 =A0 Option: IA Prefix (26)
> =A0 =A0 =A0 =A0 =A0 =A0 Length: 25
> =A0 =A0 =A0 =A0 =A0 =A0 Value: 00000000000000003c000000000000000000000= 000000000...
> =A0 =A0 =A0 =A0 =A0 =A0 Preferred lifetime: 0
> =A0 =A0 =A0 =A0 =A0 =A0 Valid lifetime: 0
> =A0 =A0 =A0 =A0 =A0 =A0 Prefix length: 60
> =A0 =A0 =A0 =A0 =A0 =A0 Prefix address: :: (::)
>
> 0000 =A033 33 00 01 00 02 c4 3d c7 b0 8f 41 86 dd 60 00 =A0 33.....=3D= ...A..`.
> 0010 =A000 00 00 7d 11 01 fe 80 00 00 00 00 00 00 c6 3d =A0 ...}......= .....=3D
> 0020 =A0c7 ff fe b0 8f 41 ff 02 00 00 00 00 00 00 00 00 =A0 .....A....= ......
> 0030 =A000 00 00 01 00 02 02 22 02 23 00 7d da 1c 01 45 =A0 .......&qu= ot;.#.}...E
> 0040 =A0eb 91 00 08 00 02 ff ff 00 06 00 0a 00 17 00 18 =A0 ..........= ......
> 0050 =A000 38 00 16 00 15 00 01 00 0a 00 03 00 01 c4 3d =A0 .8........= .....=3D
> 0060 =A0c7 b0 8f 41 00 14 00 00 00 27 00 0a 00 07 63 65 =A0 ...A.....&= #39;....ce
> 0070 =A072 6f 77 72 74 00 00 03 00 0c 00 00 00 01 00 00 =A0 rowrt.....= ......
> 0080 =A000 00 00 00 00 00 00 19 00 29 00 00 00 01 00 00 =A0 .........)= ......
> 0090 =A000 00 00 00 00 00 00 1a 00 19 00 00 00 00 00 00 =A0 ..........= ......
> 00a0 =A000 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 =A0 ..<....= .........
> 00b0 =A000 00 00 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0...
>
> The CeroWRT system log is attached. =A0Nothing looks strange except th= e
> 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). =A0My PC's NIC link = went down
> at exactly the same time. =A0At 7:24 is when I unplugged CeroWRT.
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@l= ists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



--
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

--001a11c2a20cc7ba9b04f15d5c70--