From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (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 E287821F205 for ; Fri, 7 Feb 2014 19:52:01 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i17so7523605qcy.11 for ; Fri, 07 Feb 2014 19:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0Ebz5sSZ4WjQLLjpR2LDKTrplygXzRFi6zzbmHNtU28=; b=PUOLFfrxUzh5UDUNt3mFwdfKD/zGSWz1Kjj1SFBBo54kbQOzVc+0Tw0LNHEps/EUa9 FaNSZMwxS7wbiG2KrZbSRxJKV8SHKv2JQ6Ozh5VAehzHie571wctAr/pHUu1V5WxZFMW diHfeH8JVLnSO2kMKjAZVJOmAj7+bfn/ob+QYoujU0D1rkz8xKYoiEFYtMKCrZYbrAOm QVMnX1teVWFiTgkKKCPlOJSO6h40gFaOQO4y0TYXSaTWzkhX2iMVcTjmhOVrxzeNoX3d TPQC+qniD0iedYn1HUnShm6Ol6ytx0ItvPTPMuJlXtrTks9R1EELtZwseVctjyGxrNx7 Enhw== MIME-Version: 1.0 X-Received: by 10.140.98.135 with SMTP id o7mr26042201qge.102.1391831520783; Fri, 07 Feb 2014 19:52:00 -0800 (PST) Received: by 10.224.27.133 with HTTP; Fri, 7 Feb 2014 19:52:00 -0800 (PST) Received: by 10.224.27.133 with HTTP; Fri, 7 Feb 2014 19:52:00 -0800 (PST) In-Reply-To: References: <0DA7F25C-4877-43C5-8069-FEBE2728281F@gmx.de> <954DF955-F94C-4392-83D6-AD21C05C189F@gmx.de> Date: Fri, 7 Feb 2014 19:52:00 -0800 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: multipart/alternative; boundary=001a11394e6e6248e904f1dd07e4 Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] ipv6 over DT 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, 08 Feb 2014 03:52:02 -0000 --001a11394e6e6248e904f1dd07e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Feb 7, 2014 10:46 AM, "Sebastian Moeller" wrote: > > Hi Mikael, hi Dave, > > On Feb 7, 2014, at 19:33 , Dave Taht wrote: > > > get rid of the fd route, and or try traceroute with the -s option > > So on cerowrt (as secondary router) "traceroute ipv6.google.com" works just as well as traceroute -s my_wan_interface_IP6 ipv6.google.com. >From the linux machine sitting in cero's se00 subnet, neither of these work= . The more correct test is -s my se00 address. Which doesn't have an address in your paste below. > > > > > > (and take this public please, I'm terribly buried right now) > > Oops, sorry Dave. I will try to keep this public. > > Best Regards > sebastian > > > > > On Fri, Feb 7, 2014 at 1:16 PM, Sebastian Moeller wrote: > >> Hi Mikael, > >> > >> On Feb 7, 2014, at 19:11 , Mikael Abrahamsson wrote= : > >> > >>> > >>> What does "ip -6 a l" and "ip -6 r l" say? > >> > >> On cerowrt: > >> root@nacktmulle:~# ip -6 a l > >> 1: lo: mtu 65536 > >> inet6 ::1/128 scope host > >> valid_lft forever preferred_lft forever > >> 2: se00: mtu 1500 qlen 1000 > >> inet6 fe80::a021:b7ff:feb9:5c22/64 scope link > >> valid_lft forever preferred_lft forever > >> 3: ge00: mtu 1500 qlen 1000 > >> inet6 2003:6b:f2a:9c01:a221:b7ff:feb9:5c23/64 scope global dynamic > >> valid_lft 14328sec preferred_lft 1728sec > >> inet6 fd65:570:d00e:1:a221:b7ff:feb9:5c23/64 scope global dynamic > >> valid_lft 1814328sec preferred_lft 604728sec > >> inet6 fe80::a221:b7ff:feb9:5c23/64 scope link > >> valid_lft forever preferred_lft forever > >> 6: ifb0: mtu 1500 qlen 32 > >> inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link > >> valid_lft forever preferred_lft forever > >> 14: gw11: mtu 1500 qlen 1000 > >> inet6 fe80::a221:b7ff:feb9:5c24/64 scope link > >> valid_lft forever preferred_lft forever > >> 15: gw01: mtu 1500 qlen 1000 > >> inet6 fe80::a221:b7ff:feb9:5c22/64 scope link > >> valid_lft forever preferred_lft forever > >> 16: sw10: mtu 1500 qlen 1000 > >> inet6 fe80::a021:b7ff:feb9:5c24/64 scope link > >> valid_lft forever preferred_lft forever > >> 17: sw00: mtu 1500 qlen 1000 > >> inet6 fe80::a021:b7ff:feb9:5c22/64 scope link > >> valid_lft forever preferred_lft forever > >> 18: gw00: mtu 1500 qlen 1000 > >> inet6 fe80::a421:b7ff:feb9:5c22/64 scope link > >> valid_lft forever preferred_lft forever > >> 19: gw10: mtu 1500 qlen 1000 > >> inet6 fe80::a421:b7ff:feb9:5c24/64 scope link > >> valid_lft forever preferred_lft forever > >> > >> > >> root@nacktmulle:~# ip -6 r l > >> default from :: via fe80::1 dev ge00 proto static metric 512 > >> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge00 proto static metric 512 > >> default from fd65:570:d00e:1::/64 via fe80::1 dev ge00 proto static metric 512 > >> fe80::/64 dev se00 proto kernel metric 256 > >> fe80::/64 dev ge00 proto kernel metric 256 > >> fe80::/64 dev sw00 proto kernel metric 256 > >> fe80::/64 dev sw10 proto kernel metric 256 > >> fe80::/64 dev gw00 proto kernel metric 256 > >> fe80::/64 dev gw10 proto kernel metric 256 > >> fe80::/64 dev ifb0 proto kernel metric 256 > >> fe80::/64 dev gw01 proto kernel metric 256 > >> fe80::/64 dev gw11 proto kernel metric 256 > >> > >> > >> on the connected linux box: > >> moeller@happy-horse:~> ip -6 r l > >> 2003:6b:f2a:9c01::/64 dev eth0 proto kernel metric 256 expires 14387sec > >> fd65:570:d00e:1::/64 dev eth0 proto kernel metric 256 expires 1814387sec > >> fe80::/64 dev eth0 proto kernel metric 256 > >> default via fe80::a021:b7ff:feb9:5c22 dev eth0 proto ra metric 1024 expires 167sec > >> > >> > >> moeller@happy-horse:~> ip -6 a l > >> 1: lo: mtu 65536 > >> inet6 ::1/128 scope host > >> valid_lft forever preferred_lft forever > >> 2: eth0: mtu 1500 qlen 1000 > >> inet6 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 scope global dynamic > >> valid_lft 14383sec preferred_lft 1783sec > >> inet6 fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 scope global dynamic > >> valid_lft 1814383sec preferred_lft 604783sec > >> inet6 fe80::2a92:4aff:fe30:5dbe/64 scope link > >> valid_lft forever preferred_lft forever > >> moeller@happy-horse:~> > >> > >> > >>> > >>> I'm nostly interested in if there is a route for the delegated prefix or if DHCPv6-PD failed. > >> > >> What is your verdict, based on the information above? > >> > >> Best Regards > >> Sebastian > >> > >> > >>> > >>> On Fri, 7 Feb 2014, Sebastian Moeller wrote: > >>> > >>>> Hi Dave, > >>>> > >>>> small update... > >>>> > >>>> from the router: > >>>> root@nacktmulle:~# ping -6 -c 1 ipv6.google.com > >>>> PING ipv6.google.com (2a00:1450:4008:801::1009): 56 data bytes > >>>> 64 bytes from 2a00:1450:4008:801::1009: seq=3D0 ttl=3D57 time=3D70.7= 64 ms > >>>> > >>>> --- ipv6.google.com ping statistics --- > >>>> 1 packets transmitted, 1 packets received, 0% packet loss > >>>> round-trip min/avg/max =3D 70.764/70.764/70.764 ms > >>>> > >>>> > >>>> So it seems cerowrt itself has ip6 connectivity, and what fails is passing tho on to the connected networks/interfaces, at least partly, > >>>> as my macbook gets: > >>>> hms-beagle:test moeller$ ifconfig > >>>> en1: flags=3D8863 mtu 1500 > >>>> ether 68:a8:6d:3d:c5:8c > >>>> inet6 fe80::6aa8:6dff:fe3d:c58c%en1 prefixlen 64 scopeid 0x5 > >>>> inet6 fd65:570:d00e:1:6aa8:6dff:fe3d:c58c prefixlen 64 autoconf > >>>> inet6 fd65:570:d00e:1:2998:55c2:d019:ad3c prefixlen 64 autoconf temporary > >>>> inet6 2003:6b:f2a:9c01:6aa8:6dff:fe3d:c58c prefixlen 64 autoconf > >>>> inet6 2003:6b:f2a:9c01:499c:a3dd:b91c:abc6 prefixlen 64 autoconf temporary > >>>> inet 172.30.42.112 netmask 0xffffffe0 broadcast 172.30.42.127 > >>>> media: autoselect > >>>> status: active > >>>> > >>>> but: > >>>> hms-beagle:test moeller$ ping6 -c 1 ipv6.google.com > >>>> PING6(56=3D40+8+8 bytes) 2003:6b:f2a:9c01:499c:a3dd:b91c:abc6 --> 2a00:1450:4008:801::1003 > >>>> > >>>> --- ipv6.l.google.com ping6 statistics --- > >>>> 1 packets transmitted, 0 packets received, 100.0% packet loss > >>>> > >>>> So somehow what used to be the default gateway under ip4 seems to be misconfigured... > >>>> > >>>> > >>>> On Feb 6, 2014, at 22:06 , Dave Taht wrote: > >>>> > >>>>> Changing the title of this thread as it's forked something incredible. > >>>>> > >>>>> On Thu, Feb 6, 2014 at 2:41 PM, Sebastian Moeller wrote: > >>>>>> Hi Mikael, > >>>>>> > >>>>>> thank you so much. I got a bit further, by enabling relaying I now routinely get IP6 addresses on the connected machines. > >>>>> > >>>>>> Note to Dave, in /et/config/dhcp I replaced the 'server' occurrences with 'hybrid', under the assumption that hybrid will act as server if a prefix was delegated and fall back to relay if not; might be interesting to test whether this also works with comcast's IP6). > >>>>> > >>>>> Well, hybrid is there to work with dnsmasq mostly, so in that case you > >>>>> need to enable dnsmasq's handling of RAs in /etc/dnsmasq.conf. > >>>> > >>>> From http://wiki.openwrt.org/doc/uci/network6#native.ipv6.connection it looks like hybrid tries PD first and then falls back to relay (but I do not claim I understand any of this) > >>>> > >>>> Router Advertisement & DHCPv6 > >>>> > >>>> OpenWrt features a versatile RA & DHCPv6 server and relay. Per default SLAAC, stateless and stateful DHCPv6 are enabled on an interface. If there are prefix of size /64 or greater present then addresses will be handed out from each prefix. If all prefixes on an interface have a size greater /64 then DHCPv6-Prefix Delegation is enabled for downstream-routers. If a default route is present the router advertises itself as default router on the interface. > >>>> > >>>> OpenWrt is also able to detect when there is no prefix available from an upstream interface and can switch into relaying mode automatically to extend the upstream interface configuration onto its downstream interfaces. This is useful for putting an OpenWrt behind another IPv6-router which doesn't offer prefixes via DHCPv6-PD. > >>>> > >>>> Example configuration section (/etc/config/dhcp) > >>>> > >>>> config dhcp lan > >>>> option dhcpv6 hybrid > >>>> option ra hybrid > >>>> option ndp hybrid > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> Still, there should be a way to correctly configure ND proxying in = a > >>>>> multi-lan environment in the base system with odhcpd. > >>>> > >>>> I think the "option ndp 'something'" are missing in 3.10.28-1, the version I am still using... > >>>> > >>>>> I think looking > >>>>> at the original openwrt configuration for such might be productive. > >>>> > >>>> Good idea, I will try my luck and report back if there is anything new. > >>>> > >>>>> > >>>>> But it is still not the correct way to get /60s. It's not clear to me > >>>>> if DT is using 6rd or not. > >>>> > >>>> Nor do I, what I learned is supposedly they assign a /64 to the modem/router, and then use PD to delegate a /56; but their supplied modem/router only hands out /64 to connected machines. (And I am lost in IP6, I would have guessed that a /64 should be plenty to subnet for cerowrt's needs ;) ) > >>>> How would I test for 6rd? According to wikipedia I should expect substrings of the IP4 to show up in the IP6, but I do not really see this > >>>> My current public IP4 address is: 217.86.112.208 (in hex: D9.56.70.D0) > >>>> And my current IP6 prefix is: 2003:6b:f2a:9c00:: /56 > >>>> the primary (non-cerowrt) routers internal IP6 is: 2003:6b:f2a:9c01:366b:d3ff:fe45:4937/64 (LAN) > >>>> the primary (non-cerowrt) routers external IP6 is : 2003:6b:f7f:aaa6:366b:d3ff:fe45:4938/64 (WAN) > >>>> > >>>> Does that tell you anything? > >>>> > >>>> > >>>>> > >>>>> I have discovered that several forms of tunnelling no longer work > >>>>> (sigh, 1 step forward, 2 back) on networks like AT&Ts. This shows some > >>>>> documentation on how people used to get 6rd up on AT&T > >>>>> > >>>>> https://www.tunnelbroker.net/forums/index.php?topic=3D2293.0 > >>>>> > >>>>> And this reports it broken. > >>>>> > >>>>> http://www.dslreports.com/forum/r28530086-AT-T-now-blocking-IPv6-tunnels > >>>>> > >>>>> I have ordered a ipv6 capable dsl box for the one AT&T based network I > >>>>> have access to. > >>>>> > >>>>> I still haven't got hurricane electric to work again on comcast, > >>>>> either, since I got an ipv6 capable modem. This has caused all sort= s > >>>>> of renumbering headaches... and I don't know what to point fingers at. > >>>> > >>>> interesting, I have not tried a tunnel yet (and would prefer to avoid that since native ip6 seems just a grasp away ;) ) > >>>> > >>>>> > >>>>> > >>>>>> What does not work at all is routing, none of the mains with IP6 addresses after and >including the cerowrt router can actually reach the internet via ip6. When I connect my >laptop (macosx 10.8.5) directly to the DT supplied modem/router I get working p6 >connectivity to the internet according to http://test-ipv6.com, the same test fails behind >the cerowrt router. > >>>>> > >>>>> ip -6 route show would help on the cero box and the host. > >>>> > >>>> Okay, so here is cerowrt: > >>>> root@nacktmulle:~# ip -6 route > >>>> default from :: via fe80::1 dev ge00 proto static metric 512 > >>>> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge00 proto static metric 512 > >>>> default from fd65:570:d00e:1::/64 via fe80::1 dev ge00 proto static metric 512 > >>>> fe80::/64 dev se00 proto kernel metric 256 > >>>> fe80::/64 dev ge00 proto kernel metric 256 > >>>> fe80::/64 dev sw00 proto kernel metric 256 > >>>> fe80::/64 dev sw10 proto kernel metric 256 > >>>> fe80::/64 dev gw00 proto kernel metric 256 > >>>> fe80::/64 dev gw10 proto kernel metric 256 > >>>> fe80::/64 dev ifb0 proto kernel metric 256 > >>>> fe80::/64 dev gw01 proto kernel metric 256 > >>>> fe80::/64 dev gw11 proto kernel metric 256 > >>>> > >>>> and here from happy-horse (my linux box on se00): > >>>> moeller@happy-horse:~> ip -6 route > >>>> 2003:6b:f2a:9c01::/64 dev eth0 proto kernel metric 256 expires 14360sec > >>>> fd65:570:d00e:1::/64 dev eth0 proto kernel metric 256 expires 1814360sec > >>>> fe80::/64 dev eth0 proto kernel metric 256 > >>>> default via fe80::a021:b7ff:feb9:5c22 dev eth0 proto ra metric 1024 expires 140sec > >>>> > >>>> with: > >>>> moeller@happy-horse:~> sudo /sbin/ifconfig > >>>> root's password: > >>>> eth0 Link encap:Ethernet HWaddr 28:92:4A:30:5D:BE > >>>> inet addr:172.30.42.22 Bcast:172.30.42.31 Mask:255.255.255.224 > >>>> inet6 addr: 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 Scope:Global > >>>> inet6 addr: fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 Scope:Global > >>>> inet6 addr: fe80::2a92:4aff:fe30:5dbe/64 Scope:Link > >>>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > >>>> RX packets:181875378 errors:0 dropped:0 overruns:0 frame:0 > >>>> TX packets:96658636 errors:0 dropped:0 overruns:0 carrier:0 > >>>> collisions:0 txqueuelen:1000 > >>>> RX bytes:265753690758 (253442.4 Mb) TX bytes:15245790971 (14539.5 Mb) > >>>> Interrupt:18 > >>>> > >>>> happy-horse cannot ping6 : > >>>> moeller@happy-horse:~> ping6 -c1 ipv6.google.com > >>>> PING ipv6.google.com(lax04s08-in-x00.1e100.net) 56 data bytes > >>>> > >>>> --- ipv6.google.com ping statistics --- > >>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>>> Unfortunately the ip6 handling of openwrt currently seems in heavy >flux and the documentations is a bit behind, so it is a nice challenge to get this going. > >>>>> > >>>>> No kidding. > >>>> > >>>> It looks like somethings got just fixed in odhcpd that might be relevant: > >>>> https://github.com/sbyx/odhcpd/commit/b618ad5373ae619e3d01a49f2c672a8cc1dc5= 9a6 > >>>> > >>>> I am impressed by the rate of change in openwrt currently, and the amount of infrastructure work they are doing but it makes the learning curve almost vertical given the lag of the documentation... > >>>> > >>>>> > >>>>>> Getting information "straight from the horse's mouths" obviously would be really great. > >>>>> > >>>>> We'll get it sorted as time allows. Exciting times! > >>>> > >>>> Great. My internet works really well, in a big part thanks to your great work on cerowrt. Getting ip6 to work is not urgent for me, so please do not waste too much time on this (my secret hope is that is going to be fixed magically by openwrt upstream if we wait long enough ;) ) > >>>> > >>>> Best Regards > >>>> Sebastian > >>>> > >>>>> > >>>>>> Thanks for you help > >>>>>> Best Regards > >>>>>> Sebastian > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Feb 6, 2014, at 15:14 , Mikael Abrahamsson wrote: > >>>>>> > >>>>>>> > >>>>>>> I forwarded this internally but I have yet to receive a response. I'll ping them again. > >>>>>>> > >>>>>>> On Sun, 26 Jan 2014, Dave Taht wrote: > >>>>>>> > >>>>>>>> I don't know a lot about DT and their ipv6 support. > >>>>>>>> > >>>>>>>> It sounds like they are not using dhcpv6pd, or there is some other option > >>>>>>>> you need to supply. > >>>>>>>> > >>>>>>>> Perhaps Mikael (ccd) knows. > >>>>>>>> On Jan 26, 2014 3:42 PM, "Sebastian Moeller" wrote: > >>>>>>>> > >>>>>>>>> Hi Dave, > >>>>>>>>> > >>>>>>>>> so 3.10.28-1 seems to work quite well (if I do not jinx anything by saying > >>>>>>>>> after only 1 hour testing ;) ). > >>>>>>>>> > >>>>>>>>> Doing: > >>>>>>>>> ./netperf-wrapper -l 60 -H gw.home.lan rrul -p all_scaled -disable-log -t > >>>>>>>>> hms-beagle_cerowrt3.10.21-1_2_nacktmulle > >>>>>>>>> > >>>>>>>>> still earns me: > >>>>>>>>> [ 1473.128906] ath: phy1: Failed to stop TX DMA, queues=3D0x00e= ! > >>>>>>>>> root@nacktmulle:~# cat /sys/kernel/debug/ieee80211/phy1/ath9k/reset > >>>>>>>>> Baseband Hang: 0 > >>>>>>>>> Baseband Watchdog: 0 > >>>>>>>>> Fatal HW Error: 0 > >>>>>>>>> TX HW error: 0 > >>>>>>>>> TX Path Hang: 1 > >>>>>>>>> PLL RX Hang: 0 > >>>>>>>>> MCI Reset: 0 > >>>>>>>>> > >>>>>>>>> But this is not changed. Unaligned instructions are still at 0, by the way. > >>>>>>>>> > >>>>>>>>> Now, me biggest question is how can I join the ip6 fun? My ISP > >>>>>>>>> deutsche telekom supplies my primary router/modem combo (supplied by > >>>>>>>>> telekom) with a /56 as far as I know, this router however only passes /64s > >>>>>>>>> on, so cerowrt sees: > >>>>>>>>> Address: 2003:6b:f2a:9c01:a221:b7ff:feb9:5c23/64 > >>>>>>>>> Gateway: FE80:0:0:0:0:0:0:1 > >>>>>>>>> Connected: 0h 30m 31s > >>>>>>>>> > >>>>>>>>> But the other interfaces see nothing (from log read): > >>>>>>>>> Sun Jan 26 21:19:00 2014 daemon.warn odhcpd[965]: A default route is > >>>>>>>>> present but there is no public prefix on sw10 thus we don't announce a > >>>>>>>>> default route! > >>>>>>>>> > >>>>>>>>> Do you, by chance know what I did wrong? (Or is a /64 too little?) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> best regards > >>>>>>>>> Sebastian > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Jan 26, 2014, at 20:15 , Dave Taht wrote: > >>>>>>>>> > >>>>>>>>>> Yea I think it was 2. > >>>>>>>>>> > >>>>>>>>>> I have been running with 1 to no messages thanks for looking it up. :-) > >>>>>>>>>> > >>>>>>>>>> I put out a 3.10.28-1 today in the comcast subdir. > >>>>>>>>>> > >>>>>>>>>> Ssh... Don't tell anyone. > >>>>>>>>>> > >>>>>>>>>> Toatally untested has all the procd work to date in it although I may > >>>>>>>>> have goofed on rngd.... > >>>>>>>>>> > >>>>>>>>>> Getting on a plane in 2 hrs. > >>>>>>>>>> > >>>>>>>>>> On Jan 26, 2014 1:42 PM, "Sebastian Moeller" wrote: > >>>>>>>>>> Hi Dave, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht wrote: > >>>>>>>>>> > >>>>>>>>>>> On Tue, Jan 21, 2014 at 3:59 PM, Dave Taht < dave.taht@gmail.com> > >>>>>>>>> wrote: > >>>>>>>>>>>> This is a special release intended only for comcast users with ipv6 > >>>>>>>>>>>> capable modems and CMTSes. > >>>>>>>>>>> > >>>>>>>>>>> There have been several testers getting back to me privately. All > >>>>>>>>> report > >>>>>>>>>>> good results IF you reflash from scratch. > >>>>>>>>>>> > >>>>>>>>>>> the biggest problem people have had is the switch to https vs http > >>>>>>>>>>> for the gui, their webbrowsers' cache rewrite the url back to http, > >>>>>>>>>>> and lighttpd, > >>>>>>>>>>> unlike apache, doesn't give any sign as to why the connection is > >>>>>>>>>>> not working. > >>>>>>>>>>> > >>>>>>>>>>> remember: https://gw.home.lan:81 from now on... > >>>>>>>>>>> ^^ > >>>>>>>>>>>> NOTE: If you are running any form of tunneling for ipv6 (e.g= . > >>>>>>>>> hurricane) > >>>>>>>>>>>> do NOT try this release, as it breaks badly. > >>>>>>>>>>> > >>>>>>>>>>> It turns out that source-specific routing for he tunneling is what is > >>>>>>>>> broken. > >>>>>>>>>>> It's not broken if you turn off sourcerouting in the 6in4 > >>>>>>>>> /etc/config/network > >>>>>>>>>>> stanza by adding > >>>>>>>>>>> > >>>>>>>>>>> option sourcerouting '0' > >>>>>>>>>>> > >>>>>>>>>>> The bug is also specific to cerowrt. the openwrt folk report it works > >>>>>>>>> for them. > >>>>>>>>>>> > >>>>>>>>>>> As a temporary workaround, IF you try this unrelease and still want a > >>>>>>>>> tunnel > >>>>>>>>>>> up, add the above to your 6in4 configuration. Hopefully we'll find an > >>>>>>>>> answer > >>>>>>>>>>> soon, sourcerouting solves a whole raft of other problems if applied > >>>>>>>>>>> consistently. > >>>>>>>>>>> > >>>>>>>>>>> I am otherwise pretty happy with this unrelease, I've been running it > >>>>>>>>> all week, > >>>>>>>>>>> with only 4 instruction traps in the last 20 hours. > >>>>>>>>>>> > >>>>>>>>>>> Finding these last instruction traps is going to be a PITA. Can I > >>>>>>>>> encourage > >>>>>>>>>>> people to add this to their config? > >>>>>>>>>>> > >>>>>>>>>>> echo 1 > /sys/kernel/debug/mips/unaligned_action > >>>>>>>>>> > >>>>>>>>>> Since I am about to upgrade to 3.10.26-7 (the syncs are not done but I > >>>>>>>>> had to stop them temporarily anyway) do you mean > >>>>>>>>>> > >>>>>>>>>> echo 2 > /sys/kernel/debug/mips/unaligned_action > >>>>>>>>>> > >>>>>>>>>> as according to http://www.linux-mips.org/wiki/Alignment > >>>>>>>>>> Mode Action > >>>>>>>>>> 0 silently fixup the unaligned access > >>>>>>>>>> 1 send SIGBUS > >>>>>>>>>> 2 dump registers, process name, etc. and fixup > >>>>>>>>>> > >>>>>>>>>> and the last seems to be the most convenient for finding the culprits > >>>>>>>>> yet having a still functional router; then again I might have gotten this > >>>>>>>>> wrong. Please advise > >>>>>>>>>> > >>>>>>>>>> Best Regards > >>>>>>>>>> Sebastian > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> and check their logfile once in a while, perhaps we can isolate where > >>>>>>>>> and > >>>>>>>>>>> why it happens. > >>>>>>>>>>> > >>>>>>>>>>> I went to town last night adding procd support to various easy daemons, > >>>>>>>>>>> it gets simpler after the first 3... > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.26-7/ > >>>>>>>>>>>> > >>>>>>>>>>>> I strongly recommend all cerowrt users on comcast, upgrade.[1] > >>>>>>>>>>>> > >>>>>>>>>>>> If you are on comcast and dare not upgrade to this, comment out these > >>>>>>>>>>>> lines in /etc/config/network > >>>>>>>>>>>> > >>>>>>>>>>>> #config interface ge01 # wan6 on some release. > >>>>>>>>>>>> # option ifname @ge00 > >>>>>>>>>>>> # option proto dhcpv6 > >>>>>>>>>>>> # option 'broadcast' '1' > >>>>>>>>>>>> # option 'metric' '2048' > >>>>>>>>>>>> # option 'reqprefix' '60' > >>>>>>>>>>>> > >>>>>>>>>>>> and reboot to disable dhcpv6 on the external interface entirely. > >>>>>>>>>>> > >>>>>>>>>>> I still recomend that everyone on comcast & not running this release > >>>>>>>>> do this. > >>>>>>>>>>> > >>>>>>>>>>>> I have been having flashbacks to the IPX/SPX transition... but it > >>>>>>>>>>>> really did bring a tear to my eye to finally have ipv6 connectivity > >>>>>>>>>>>> for the first time, native. And to see no real difference in RTT > >>>>>>>>>>>> between ipv4 and v6. > >>>>>>>>>>>> > >>>>>>>>>>>> http://snapon.lab.bufferbloat.net/~d/bev/comcast_native_ipv6= / > >>>>>>>>>>>> > >>>>>>>>>>>> Oh brave new world that may have new protocols in it. > >>>>>>>>>>>> > >>>>>>>>>>>> A bunch of other stuff landed in cero, and if you are not tunneling, > >>>>>>>>>>>> and your spouse and family are willing, you can try: > >>>>>>>>>>>> > >>>>>>>>>>>> + openwrt sync from head > >>>>>>>>>>>> + RA spamming filter stopping mega firewall reloads on comcast ipv6 - > >>>>>>>>>>>> thx steven barth! > >>>>>>>>>>>> + switch from dnsmasq to using odhcpd for ipv6 RAs (thx #openwrt!) > >>>>>>>>>>>> + Comcast ipv6 actually tested by me > >>>>>>>>>>>> + GUI is now https - thx sebastian! (we still have some work left > >>>>>>>>> here) > >>>>>>>>>>>> For snowden points, it also does perfect forward secrecy. > >>>>>>>>>>>> + GUI has selectable skins (pick one, any one) > >>>>>>>>>>>> + SQM starts correctly on boot and other restarts > >>>>>>>>>>>> + SQM now scales better to higher rates > >>>>>>>>>>>> + updated on-board documentation ( example: > >>>>>>>>>>>> http://cero2.bufferbloat.net/cerowrt/index.html ) > >>>>>>>>>>>> + updated uftp, ccnx, new libnettle package (for dnsmasq 2.69) - thx > >>>>>>>>>>>> stephen walker > >>>>>>>>>>>> + sysupgrade fixed > >>>>>>>>>>>> > >>>>>>>>>>>> on the minus side > >>>>>>>>>>>> > >>>>>>>>>>>> - We still have some timing problems in picking up the RAs, > >>>>>>>>>>>> particularly from wifi. > >>>>>>>>>>>> If you don't get ipv6 addresses on your wifi client after a fresh > >>>>>>>>>>>> boot of cero, > >>>>>>>>>>>> reconnect the wifi client. After cero is fully booted. and has > >>>>>>>>>>>> dhcpv6-pd'd addresses, you'll get them. Usually. > >>>>>>>>>>>> > >>>>>>>>>>>> - bcp38: didn't get 'round2it src/dst routing solves half of it > >>>>>>>>>>>> - updated shaperprobe, ditg, same > >>>>>>>>>>>> - HT40+ DOES appear to be NOT working. (this has been the case for a > >>>>>>>>> while) > >>>>>>>>>>>> - Hurricane electric ipv6 tunnels are *badly broken* as in *will > >>>>>>>>>>>> disable your router* with a zillion extra processes. > >>>>>>>>>>>> > >>>>>>>>>>>> a huge change in openwrt made saturday was a switch to sourc= e > >>>>>>>>> specific routing, > >>>>>>>>>>>> > >>>>>>>>>>>> e.g, if you have two ipv6 providers, (or a vpn, and so on) > >>>>>>>>>>>> stuff from source A will go out the right destination for destination > >>>>>>>>> A, > >>>>>>>>>>>> and stuff from source B will go out the right destination fo= r > >>>>>>>>>>>> destination B. At least in theory. > >>>>>>>>>>>> > >>>>>>>>>>>> so you will see "from" routes. > >>>>>>>>>>>> > >>>>>>>>>>>> root@cerowrt:~# ip -6 route > >>>>>>>>>>>> default from :: via fe80::201:5cff:de41:b841 dev ge00 proto static > >>>>>>>>> metric 1024 > >>>>>>>>>>>> default from 2001:E:L:I:D:E:D:Z via fe80::201:5ccf:fe41:b841 dev ge00 > >>>>>>>>>>>> proto static metric 1024 > >>>>>>>>>>>> default from 2601:X:Y::0::/60 via fe80::201:5ccf:fe41:b841 dev ge00 > >>>>>>>>>>>> proto static metric 1024 > >>>>>>>>>>>> 2601:X:Y:0::/64 dev gw00 proto kernel metric 256 expires 345262sec > >>>>>>>>>>>> 2601:X:Y:1::/64 dev gw10 proto kernel metric 256 expires 345262sec > >>>>>>>>>>>> 2601:X:Y:2::/64 dev se00 proto kernel metric 256 expires 345262sec > >>>>>>>>>>>> 2601:X:Y:3::/64 dev sw00 proto kernel metric 256 expires 345262sec > >>>>>>>>>>>> 2601:X:Y:4::/64 dev sw10 proto kernel metric 256 expires 345262sec > >>>>>>>>>>>> unreachable 2601:X:X:0::/60 dev lo proto static metric 2147483647 > >>>>>>>>> error -128 > >>>>>>>>>>>> > >>>>>>>>>>>> I figure there is much work to be done to get things like ipsec and > >>>>>>>>> openvpn > >>>>>>>>>>>> and bird/quagga/babeld to work well again, but source/dest routing was > >>>>>>>>>>>> desparately needed, so... > >>>>>>>>>>>> > >>>>>>>>>>>> [1] All my testing was done on an ARRIS TM822G cablemodem. (I have a > >>>>>>>>> profoundly > >>>>>>>>>>>> low opinion of several other cablemodems, notably the technicolor...) > >>>>>>>>>>>> There are a few other testers on other cablemodems, please report > >>>>>>>>>>>> in... > >>>>>>>>>>>> > >>>>>>>>>>>> I return now to my regularly scheduled workweek from last wednesday. > >>>>>>>>>>>> Share and enjoy. > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Dave T=E4ht > >>>>> > >>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html > >>>> > >>> > >>> -- > >>> Mikael Abrahamsson email: swmike@swm.pp.se > >> > > > > > > > > -- > > Dave T=E4ht > > > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html > --001a11394e6e6248e904f1dd07e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Feb 7, 2014 10:46 AM, "Sebastian Moeller" <moeller0@gmx.de> wrote:
>
> Hi Mikael, hi Dave,
>
> On Feb 7, 2014, at 19:33 , Dave Taht <dave.taht@gmail.com> wrote:
>
> > get rid of the fd route, and or try traceroute with the -s option=
>
> =A0 =A0 =A0 =A0 So on cerowrt (as secondary router) "traceroute <= a href=3D"http://ipv6.google.com">ipv6.google.com" works just as w= ell as traceroute -s my_wan_interface_IP6 ipv6.google.com. From the linux machine sitting in cero's se00 su= bnet, neither of these work.

The more correct test is -s my se00 address.

Which doesn't have an address in your paste below.

>
>
> >
> > (and take this public please, I'm terribly buried right now)<= br> >
> =A0 =A0 =A0 =A0 Oops, sorry Dave. I will try to keep this public.
>
> Best Regards
> =A0 =A0 =A0 =A0 sebastian
>
> >
> > On Fri, Feb 7, 2014 at 1:16 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> >> Hi Mikael,
> >>
> >> On Feb 7, 2014, at 19:11 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> >>
> >>>
> >>> What does "ip -6 a l" and "ip -6 r l"= say?
> >>
> >> On cerowrt:
> >> root@nacktmulle:~# ip -6 a l
> >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
> >> =A0 =A0inet6 ::1/128 scope host
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qle= n 1000
> >> =A0 =A0inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qle= n 1000
> >> =A0 =A0inet6 2003:6b:f2a:9c01:a221:b7ff:feb9:5c23/64 scope gl= obal dynamic
> >> =A0 =A0 =A0 valid_lft 14328sec preferred_lft 1728sec
> >> =A0 =A0inet6 fd65:570:d00e:1:a221:b7ff:feb9:5c23/64 scope glo= bal dynamic
> >> =A0 =A0 =A0 valid_lft 1814328sec preferred_lft 604728sec
> >> =A0 =A0inet6 fe80::a221:b7ff:feb9:5c23/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 6: ifb0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 32=
> >> =A0 =A0inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 14: gw11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a221:b7ff:feb9:5c24/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 15: gw01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a221:b7ff:feb9:5c22/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 16: sw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a021:b7ff:feb9:5c24/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 17: sw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 18: gw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a421:b7ff:feb9:5c22/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 19: gw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ql= en 1000
> >> =A0 =A0inet6 fe80::a421:b7ff:feb9:5c24/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >>
> >>
> >> root@nacktmulle:~# ip -6 r l
> >> default from :: via fe80::1 dev ge00 =A0proto static =A0metri= c 512
> >> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge00 =A0pr= oto static =A0metric 512
> >> default from fd65:570:d00e:1::/64 via fe80::1 dev ge00 =A0pro= to static =A0metric 512
> >> fe80::/64 dev se00 =A0proto kernel =A0metric 256
> >> fe80::/64 dev ge00 =A0proto kernel =A0metric 256
> >> fe80::/64 dev sw00 =A0proto kernel =A0metric 256
> >> fe80::/64 dev sw10 =A0proto kernel =A0metric 256
> >> fe80::/64 dev gw00 =A0proto kernel =A0metric 256
> >> fe80::/64 dev gw10 =A0proto kernel =A0metric 256
> >> fe80::/64 dev ifb0 =A0proto kernel =A0metric 256
> >> fe80::/64 dev gw01 =A0proto kernel =A0metric 256
> >> fe80::/64 dev gw11 =A0proto kernel =A0metric 256
> >>
> >>
> >> on the connected linux box:
> >> moeller@happy-horse:~> ip -6 r l
> >> 2003:6b:f2a:9c01::/64 dev eth0 =A0proto kernel =A0metric 256 = =A0expires 14387sec
> >> fd65:570:d00e:1::/64 dev eth0 =A0proto kernel =A0metric 256 = =A0expires 1814387sec
> >> fe80::/64 dev eth0 =A0proto kernel =A0metric 256
> >> default via fe80::a021:b7ff:feb9:5c22 dev eth0 =A0proto ra = =A0metric 1024 =A0expires 167sec
> >>
> >>
> >> moeller@happy-horse:~> ip -6 a l
> >> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
> >> =A0 =A0inet6 ::1/128 scope host
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qle= n 1000
> >> =A0 =A0inet6 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe/64 scope gl= obal dynamic
> >> =A0 =A0 =A0 valid_lft 14383sec preferred_lft 1783sec
> >> =A0 =A0inet6 fd65:570:d00e:1:2a92:4aff:fe30:5dbe/64 scope glo= bal dynamic
> >> =A0 =A0 =A0 valid_lft 1814383sec preferred_lft 604783sec
> >> =A0 =A0inet6 fe80::2a92:4aff:fe30:5dbe/64 scope link
> >> =A0 =A0 =A0 valid_lft forever preferred_lft forever
> >> moeller@happy-horse:~>
> >>
> >>
> >>>
> >>> I'm nostly interested in if there is a route for the = delegated prefix or if DHCPv6-PD failed.
> >>
> >> =A0 =A0 =A0 =A0What is your verdict, based on the information= above?
> >>
> >> Best Regards
> >> =A0 =A0 =A0 =A0Sebastian
> >>
> >>
> >>>
> >>> On Fri, 7 Feb 2014, Sebastian Moeller wrote:
> >>>
> >>>> Hi Dave,
> >>>>
> >>>> small update...
> >>>>
> >>>> from the router:
> >>>> root@nacktmulle:~# ping -6 -c 1 ipv6.google.com
> >>>> PING ipv6.google.c= om (2a00:1450:4008:801::1009): 56 data bytes
> >>>> 64 bytes from 2a00:1450:4008:801::1009: seq=3D0 ttl= =3D57 time=3D70.764 ms
> >>>>
> >>>> --- ipv6.google.co= m ping statistics ---
> >>>> 1 packets transmitted, 1 packets received, 0% packet = loss
> >>>> round-trip min/avg/max =3D 70.764/70.764/70.764 ms > >>>>
> >>>>
> >>>> So it seems cerowrt itself has ip6 connectivity, and = what fails is passing tho on to the connected networks/interfaces, at least= partly,
> >>>> as my macbook gets:
> >>>> hms-beagle:test moeller$ ifconfig
> >>>> en1: flags=3D8863<UP,BROADCAST,SMART,RUNNING,SIMPL= EX,MULTICAST> mtu 1500
> >>>> =A0 =A0 ether 68:a8:6d:3d:c5:8c
> >>>> =A0 =A0 inet6 fe80::6aa8:6dff:fe3d:c58c%en1 prefixlen= 64 scopeid 0x5
> >>>> =A0 =A0 inet6 fd65:570:d00e:1:6aa8:6dff:fe3d:c58c pre= fixlen 64 autoconf
> >>>> =A0 =A0 inet6 fd65:570:d00e:1:2998:55c2:d019:ad3c pre= fixlen 64 autoconf temporary
> >>>> =A0 =A0 inet6 2003:6b:f2a:9c01:6aa8:6dff:fe3d:c58c pr= efixlen 64 autoconf
> >>>> =A0 =A0 inet6 2003:6b:f2a:9c01:499c:a3dd:b91c:abc6 pr= efixlen 64 autoconf temporary
> >>>> =A0 =A0 inet 172.30.42.112 netmask 0xffffffe0 broadca= st 172.30.42.127
> >>>> =A0 =A0 media: autoselect
> >>>> =A0 =A0 status: active
> >>>>
> >>>> but:
> >>>> hms-beagle:test moeller$ ping6 -c 1 ipv6.google.com
> >>>> PING6(56=3D40+8+8 bytes) 2003:6b:f2a:9c01:499c:a3dd:b= 91c:abc6 --> 2a00:1450:4008:801::1003
> >>>>
> >>>> --- ipv6.l.googl= e.com ping6 statistics ---
> >>>> 1 packets transmitted, 0 packets received, 100.0% pac= ket loss
> >>>>
> >>>> So somehow what used to be the default gateway under = ip4 seems to be misconfigured...
> >>>>
> >>>>
> >>>> On Feb 6, 2014, at 22:06 , Dave Taht <dave.taht@gmail.com> wrote:
> >>>>
> >>>>> Changing the title of this thread as it's for= ked something incredible.
> >>>>>
> >>>>> On Thu, Feb 6, 2014 at 2:41 PM, Sebastian Moeller= <moeller0@gmx.de> wrote:
> >>>>>> Hi Mikael,
> >>>>>>
> >>>>>> thank you so much. I got a bit further, by en= abling relaying I now routinely get IP6 addresses on the connected machines= .
> >>>>>
> >>>>>> Note to Dave, in /et/config/dhcp I replaced t= he 'server' occurrences with 'hybrid', under the assumption= that hybrid will act as server if a prefix was delegated and fall back to = relay if not; might be interesting to test whether this also works with com= cast's IP6).
> >>>>>
> >>>>> Well, hybrid is there to work with dnsmasq mostly= , so in that case you
> >>>>> need to enable dnsmasq's handling of RAs in /= etc/dnsmasq.conf.
> >>>>
> >>>> =A0 =A0 From http://wiki.openwrt.org/doc/uci/network= 6#native.ipv6.connection it looks like hybrid tries PD first and then f= alls back to relay (but I do not claim I understand any of this)
> >>>>
> >>>> Router Advertisement & DHCPv6
> >>>>
> >>>> OpenWrt features a versatile RA & DHCPv6 server a= nd relay. Per default SLAAC, stateless and stateful DHCPv6 are enabled on a= n interface. If there are prefix of size /64 or greater present then addres= ses will be handed out from each prefix. If all prefixes on an interface ha= ve a size greater /64 then DHCPv6-Prefix Delegation is enabled for downstre= am-routers. If a default route is present the router advertises itself as d= efault router on the interface.
> >>>>
> >>>> OpenWrt is also able to detect when there is no prefi= x available from an upstream interface and can switch into relaying mode au= tomatically to extend the upstream interface configuration onto its downstr= eam interfaces. This is useful for putting an OpenWrt behind another IPv6-r= outer which doesn't offer prefixes via DHCPv6-PD.
> >>>>
> >>>> Example configuration section (/etc/config/dhcp)
> >>>>
> >>>> config dhcp lan
> >>>> =A0option dhcpv6 hybrid
> >>>> =A0option ra hybrid
> >>>> =A0option ndp hybrid
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Still, there should be a way to correctly configu= re ND proxying in a
> >>>>> multi-lan environment in the base system with odh= cpd.
> >>>>
> >>>> =A0 =A0 I think the "option ndp 'something&#= 39;" are missing in 3.10.28-1, the version I am still using...
> >>>>
> >>>>> I think looking
> >>>>> at the original openwrt configuration for such mi= ght be productive.
> >>>>
> >>>> =A0 =A0 Good idea, I will try my luck and report back= if there is anything new.
> >>>>
> >>>>>
> >>>>> But it is still not the correct way to get /60s. = It's not clear to me
> >>>>> if DT is using 6rd or not.
> >>>>
> >>>> =A0 =A0 Nor do I, what I learned is supposedly they a= ssign a /64 to the modem/router, and then use PD to delegate a /56; but the= ir supplied modem/router only hands out /64 to connected machines. (And I a= m lost in IP6, I would have guessed that a /64 should be plenty to subnet f= or cerowrt's needs ;) )
> >>>> =A0 =A0 How would I test for 6rd? According to wikipe= dia I should expect substrings of the IP4 to show up in the IP6, but I do n= ot really see this
> >>>> My current public IP4 address is: 217.86.112.208 (in = hex: D9.56.70.D0)
> >>>> And my current IP6 prefix is: 2003:6b:f2a:9c00:: =A0/= 56
> >>>> the primary (non-cerowrt) routers internal IP6 is: 20= 03:6b:f2a:9c01:366b:d3ff:fe45:4937/64 (LAN)
> >>>> the primary (non-cerowrt) routers external IP6 is : 2= 003:6b:f7f:aaa6:366b:d3ff:fe45:4938/64 (WAN)
> >>>>
> >>>> Does that tell you anything?
> >>>>
> >>>>
> >>>>>
> >>>>> I have discovered that several forms of tunnellin= g no longer work
> >>>>> (sigh, 1 step forward, 2 back) on networks like A= T&Ts. This shows some
> >>>>> documentation on how people used to get 6rd up on= AT&T
> >>>>>
> >>>>> https://www.tunnelbroker.net/forums/index.php?topic= =3D2293.0
> >>>>>
> >>>>> And this reports it broken.
> >>>>>
> >>>>> http://www.dslreports.com/forum/r285300= 86-AT-T-now-blocking-IPv6-tunnels
> >>>>>
> >>>>> I have ordered a ipv6 capable dsl box for the one= AT&T based network I
> >>>>> have access to.
> >>>>>
> >>>>> I still haven't got hurricane electric to wor= k again on comcast,
> >>>>> either, since I got an ipv6 capable modem. This h= as caused all sorts
> >>>>> of renumbering headaches... and I don't know = what to point fingers at.
> >>>>
> >>>> interesting, I have not tried a tunnel yet (and would= prefer to avoid that since native ip6 seems just a grasp away ;) )
> >>>>
> >>>>>
> >>>>>
> >>>>>> What does not work at all is routing, none of= the mains with IP6 addresses after and >including the cerowrt router ca= n actually reach the internet via ip6. When I connect my >laptop (macosx= 10.8.5) directly to the DT supplied modem/router I get working p6 >conn= ectivity to the internet according to http= ://test-ipv6.com, the same test fails behind >the cerowrt router. > >>>>>
> >>>>> ip -6 route show would help on the cero box and t= he host.
> >>>>
> >>>> Okay, so here is cerowrt:
> >>>> root@nacktmulle:~# ip -6 route
> >>>> default from :: via fe80::1 dev ge00 =A0proto static = =A0metric 512
> >>>> default from 2003:6b:f2a:9c01::/64 via fe80::1 dev ge= 00 =A0proto static =A0metric 512
> >>>> default from fd65:570:d00e:1::/64 via fe80::1 dev ge0= 0 =A0proto static =A0metric 512
> >>>> fe80::/64 dev se00 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev ge00 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev sw00 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev sw10 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev gw00 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev gw10 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev ifb0 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev gw01 =A0proto kernel =A0metric 256
> >>>> fe80::/64 dev gw11 =A0proto kernel =A0metric 256
> >>>>
> >>>> and here from happy-horse (my linux box on se00):
> >>>> moeller@happy-horse:~> ip -6 route
> >>>> 2003:6b:f2a:9c01::/64 dev eth0 =A0proto kernel =A0met= ric 256 =A0expires 14360sec
> >>>> fd65:570:d00e:1::/64 dev eth0 =A0proto kernel =A0metr= ic 256 =A0expires 1814360sec
> >>>> fe80::/64 dev eth0 =A0proto kernel =A0metric 256
> >>>> default via fe80::a021:b7ff:feb9:5c22 dev eth0 =A0pro= to ra =A0metric 1024 =A0expires 140sec
> >>>>
> >>>> with:
> >>>> moeller@happy-horse:~> sudo /sbin/ifconfig
> >>>> root's password:
> >>>> eth0 =A0 =A0 =A0Link encap:Ethernet =A0HWaddr 28:92:4= A:30:5D:BE
> >>>> =A0 =A0 =A0 =A0inet addr:172.30.42.22 =A0Bcast:172.30= .42.31 =A0Mask:255.255.255.224
> >>>> =A0 =A0 =A0 =A0inet6 addr: 2003:6b:f2a:9c01:2a92:4aff= :fe30:5dbe/64 Scope:Global
> >>>> =A0 =A0 =A0 =A0inet6 addr: fd65:570:d00e:1:2a92:4aff:= fe30:5dbe/64 Scope:Global
> >>>> =A0 =A0 =A0 =A0inet6 addr: fe80::2a92:4aff:fe30:5dbe/= 64 Scope:Link
> >>>> =A0 =A0 =A0 =A0UP BROADCAST RUNNING MULTICAST =A0MTU:= 1500 =A0Metric:1
> >>>> =A0 =A0 =A0 =A0RX packets:181875378 errors:0 dropped:= 0 overruns:0 frame:0
> >>>> =A0 =A0 =A0 =A0TX packets:96658636 errors:0 dropped:0= overruns:0 carrier:0
> >>>> =A0 =A0 =A0 =A0collisions:0 txqueuelen:1000
> >>>> =A0 =A0 =A0 =A0RX bytes:265753690758 (253442.4 Mb) = =A0TX bytes:15245790971 (14539.5 Mb)
> >>>> =A0 =A0 =A0 =A0Interrupt:18
> >>>>
> >>>> happy-horse cannot ping6 :
> >>>> moeller@happy-horse:~> ping6 -c1 ipv6.google.com
> >>>> PING ipv6.google.c= om(lax04s08-in-x00.1e100.n= et) 56 data bytes
> >>>>
> >>>> --- ipv6.google.co= m ping statistics ---
> >>>> 1 packets transmitted, 0 received, 100% packet loss, = time 0ms
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>> Unfortunately the ip6 handling of openwrt cur= rently seems in heavy >flux and the documentations is a bit behind, so i= t is a nice challenge to get this going.
> >>>>>
> >>>>> No kidding.
> >>>>
> >>>> =A0 =A0 It looks like somethings got just fixed in od= hcpd that might be relevant:
> >>>> https://github.com/sbyx/odhcpd/commit= /b618ad5373ae619e3d01a49f2c672a8cc1dc59a6
> >>>>
> >>>> I am impressed by the rate of change in openwrt curre= ntly, and the amount of infrastructure work they are doing but it makes the= learning curve almost vertical given the lag of the documentation...
> >>>>
> >>>>>
> >>>>>> Getting information "straight from the h= orse's mouths" obviously would be really great.
> >>>>>
> >>>>> We'll get it sorted as time allows. Exciting = times!
> >>>>
> >>>> =A0 =A0 Great. My internet works really well, in a bi= g part thanks to your great work on cerowrt. Getting ip6 to work is not urg= ent for me, so please do not waste too much time on this (my secret hope is= that is going to be fixed magically by openwrt upstream if we wait long en= ough ;) )
> >>>>
> >>>> Best Regards
> >>>> =A0 =A0 Sebastian
> >>>>
> >>>>>
> >>>>>> Thanks for you help
> >>>>>> =A0 =A0 =A0Best Regards
> >>>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Sebastian
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Feb 6, 2014, at 15:14 , Mikael Abrahamsson= <swmike@swm.pp.se> wrote: > >>>>>>
> >>>>>>>
> >>>>>>> I forwarded this internally but I have ye= t to receive a response. I'll ping them again.
> >>>>>>>
> >>>>>>> On Sun, 26 Jan 2014, Dave Taht wrote:
> >>>>>>>
> >>>>>>>> I don't know a lot about DT and t= heir ipv6 support.
> >>>>>>>>
> >>>>>>>> It sounds like they are not using dhc= pv6pd, or there is some other option
> >>>>>>>> you need to supply.
> >>>>>>>>
> >>>>>>>> Perhaps Mikael (ccd) knows.
> >>>>>>>> On Jan 26, 2014 3:42 PM, "Sebast= ian Moeller" <moeller0@gmx.de> wrote:
> >>>>>>>>
> >>>>>>>>> Hi Dave,
> >>>>>>>>>
> >>>>>>>>> so 3.10.28-1 seems to work quite = well (if I do not jinx anything by saying
> >>>>>>>>> after only 1 hour testing ;) ). > >>>>>>>>>
> >>>>>>>>> Doing:
> >>>>>>>>> ./netperf-wrapper -l 60 -H gw.hom= e.lan rrul -p all_scaled -disable-log -t
> >>>>>>>>> hms-beagle_cerowrt3.10.21-1_2_nac= ktmulle
> >>>>>>>>>
> >>>>>>>>> still earns me:
> >>>>>>>>> [ 1473.128906] ath: phy1: Failed = to stop TX DMA, queues=3D0x00e!
> >>>>>>>>> root@nacktmulle:~# cat /sys/kerne= l/debug/ieee80211/phy1/ath9k/reset
> >>>>>>>>> Baseband Hang: =A00
> >>>>>>>>> Baseband Watchdog: =A00
> >>>>>>>>> Fatal HW Error: =A00
> >>>>>>>>> =A0 TX HW error: =A00
> >>>>>>>>> =A0TX Path Hang: =A01
> >>>>>>>>> =A0 PLL RX Hang: =A00
> >>>>>>>>> =A0 =A0 MCI Reset: =A00
> >>>>>>>>>
> >>>>>>>>> But this is not changed. Unaligne= d instructions are still at 0, by the way.
> >>>>>>>>>
> >>>>>>>>> =A0 =A0 Now, me biggest question = is how can I join the ip6 fun? My ISP
> >>>>>>>>> deutsche telekom supplies my prim= ary router/modem combo (supplied by
> >>>>>>>>> telekom) with a /56 as far as I k= now, this router however only passes /64s
> >>>>>>>>> on, so cerowrt sees:
> >>>>>>>>> Address: 2003:6b:f2a:9c01:a221:b7= ff:feb9:5c23/64
> >>>>>>>>> Gateway: FE80:0:0:0:0:0:0:1
> >>>>>>>>> Connected: 0h 30m 31s
> >>>>>>>>>
> >>>>>>>>> But the other interfaces see noth= ing (from log read):
> >>>>>>>>> Sun Jan 26 21:19:00 2014 daemon.w= arn odhcpd[965]: A default route is
> >>>>>>>>> present but there is no public pr= efix on sw10 thus we don't announce a
> >>>>>>>>> default route!
> >>>>>>>>>
> >>>>>>>>> Do you, by chance know what I did= wrong? (Or is a /64 too little?)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> best regards
> >>>>>>>>> =A0 =A0 Sebastian
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Jan 26, 2014, at 20:15 , Dave = Taht <dave.taht@gmail.com>= wrote:
> >>>>>>>>>
> >>>>>>>>>> Yea I think it was 2.
> >>>>>>>>>>
> >>>>>>>>>> I have been running with 1 to= no messages thanks for looking it up. :-)
> >>>>>>>>>>
> >>>>>>>>>> I put out a 3.10.28-1 today i= n the comcast subdir.
> >>>>>>>>>>
> >>>>>>>>>> Ssh... Don't tell anyone.=
> >>>>>>>>>>
> >>>>>>>>>> Toatally untested has all the= procd work to date in it although I may
> >>>>>>>>> have goofed on rngd....
> >>>>>>>>>>
> >>>>>>>>>> Getting on a plane in 2 hrs.<= br> > >>>>>>>>>>
> >>>>>>>>>> On Jan 26, 2014 1:42 PM, &quo= t;Sebastian Moeller" <moeller0@g= mx.de> wrote:
> >>>>>>>>>> Hi Dave,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jan 24, 2014, at 18:06 , D= ave Taht <dave.taht@gmail.com= > wrote:
> >>>>>>>>>>
> >>>>>>>>>>> On Tue, Jan 21, 2014 at 3= :59 PM, Dave Taht <dave.taht@gmai= l.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>>> This is a special rel= ease intended only for comcast users with ipv6
> >>>>>>>>>>>> capable modems and CM= TSes.
> >>>>>>>>>>>
> >>>>>>>>>>> There have been several t= esters getting back to me privately. All
> >>>>>>>>> report
> >>>>>>>>>>> good results IF you refla= sh from scratch.
> >>>>>>>>>>>
> >>>>>>>>>>> the biggest problem peopl= e have had is the switch to https vs http
> >>>>>>>>>>> for the gui, their webbro= wsers' cache rewrite the url back to http,
> >>>>>>>>>>> and lighttpd,
> >>>>>>>>>>> unlike apache, doesn'= t give any sign as to why the connection is
> >>>>>>>>>>> not working.
> >>>>>>>>>>>
> >>>>>>>>>>> remember: https://gw.home.lan:81 from now on...
> >>>>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0^^
> >>>>>>>>>>>> NOTE: If you are runn= ing any form of tunneling for ipv6 (e.g.
> >>>>>>>>> hurricane)
> >>>>>>>>>>>> do NOT try this relea= se, as it breaks badly.
> >>>>>>>>>>>
> >>>>>>>>>>> It turns out that source-= specific routing for he tunneling is what is
> >>>>>>>>> broken.
> >>>>>>>>>>> It's not broken if yo= u turn off sourcerouting in the 6in4
> >>>>>>>>> /etc/config/network
> >>>>>>>>>>> stanza by adding
> >>>>>>>>>>>
> >>>>>>>>>>> =A0 =A0option sourcerouti= ng '0'
> >>>>>>>>>>>
> >>>>>>>>>>> The bug is also specific = to cerowrt. the openwrt folk report it works
> >>>>>>>>> for them.
> >>>>>>>>>>>
> >>>>>>>>>>> As a temporary workaround= , IF you try this unrelease and still want a
> >>>>>>>>> tunnel
> >>>>>>>>>>> up, add the above to your= 6in4 configuration. =A0Hopefully we'll find an
> >>>>>>>>> answer
> >>>>>>>>>>> soon, sourcerouting solve= s a whole raft of other problems if applied
> >>>>>>>>>>> consistently.
> >>>>>>>>>>>
> >>>>>>>>>>> I am otherwise pretty hap= py with this unrelease, I've been running it
> >>>>>>>>> all week,
> >>>>>>>>>>> with only 4 instruction t= raps in the last 20 hours.
> >>>>>>>>>>>
> >>>>>>>>>>> Finding these last instru= ction traps is going to be a PITA. Can I
> >>>>>>>>> encourage
> >>>>>>>>>>> people to add this to the= ir config?
> >>>>>>>>>>>
> >>>>>>>>>>> echo 1 > /sys/kernel/d= ebug/mips/unaligned_action
> >>>>>>>>>>
> >>>>>>>>>> Since I am about to upgrade t= o 3.10.26-7 (the syncs are not done but I
> >>>>>>>>> had to stop them temporarily anyw= ay) do you mean
> >>>>>>>>>>
> >>>>>>>>>> =A0 =A0 echo 2 > /sys/kern= el/debug/mips/unaligned_action
> >>>>>>>>>>
> >>>>>>>>>> as according to http://www.linux-mips.org/wiki/Alig= nment
> >>>>>>>>>> Mode =A0 =A0Action
> >>>>>>>>>> 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= silently fixup the unaligned access
> >>>>>>>>>> 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0= send SIGBUS
> >>>>>>>>>> 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0= dump registers, process name, etc. and fixup
> >>>>>>>>>>
> >>>>>>>>>> and the last seems to be the = most convenient for finding the culprits
> >>>>>>>>> yet having a still functional rou= ter; then again I might have gotten this
> >>>>>>>>> wrong. Please advise
> >>>>>>>>>>
> >>>>>>>>>> Best Regards
> >>>>>>>>>> =A0 =A0 Sebastian
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> and check their logfile o= nce in a while, perhaps we can isolate where
> >>>>>>>>> and
> >>>>>>>>>>> why it happens.
> >>>>>>>>>>>
> >>>>>>>>>>> I went to town last night= adding procd support to various easy daemons,
> >>>>>>>>>>> it gets simpler after the= first 3...
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>> http://snapon.lab.buffe= rbloat.net/~cero2/cerowrt/wndr/comcast/3.10.26-7/
> >>>>>>>>>>>>
> >>>>>>>>>>>> I strongly recommend = all cerowrt users on comcast, upgrade.[1]
> >>>>>>>>>>>>
> >>>>>>>>>>>> If you are on comcast= and dare not upgrade to this, comment out these
> >>>>>>>>>>>> lines in /etc/config/= network
> >>>>>>>>>>>>
> >>>>>>>>>>>> #config interface ge0= 1 # wan6 on some release.
> >>>>>>>>>>>> # =A0 =A0 =A0 =A0opti= on ifname =A0 @ge00
> >>>>>>>>>>>> # =A0 =A0 =A0 =A0opti= on proto =A0 =A0dhcpv6
> >>>>>>>>>>>> # =A0 =A0 =A0 option = 'broadcast' '1'
> >>>>>>>>>>>> # =A0 =A0 =A0 =A0opti= on 'metric' '2048'
> >>>>>>>>>>>> # =A0 =A0 =A0 =A0opti= on 'reqprefix' '60'
> >>>>>>>>>>>>
> >>>>>>>>>>>> and reboot to disable= dhcpv6 on the external interface entirely.
> >>>>>>>>>>>
> >>>>>>>>>>> I still recomend that eve= ryone on comcast & not running this release
> >>>>>>>>> do this.
> >>>>>>>>>>>
> >>>>>>>>>>>> I have been having fl= ashbacks to the IPX/SPX transition... but it
> >>>>>>>>>>>> really did bring a te= ar to my eye to finally have ipv6 connectivity
> >>>>>>>>>>>> for the first time, n= ative. And to see no real difference in RTT
> >>>>>>>>>>>> between ipv4 and v6.<= br> > >>>>>>>>>>>>
> >>>>>>>>>>>> http://snapon.lab.buff= erbloat.net/~d/bev/comcast_native_ipv6/
> >>>>>>>>>>>>
> >>>>>>>>>>>> Oh brave new world th= at may have new protocols in it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> A bunch of other stuf= f landed in cero, and if you are not tunneling,
> >>>>>>>>>>>> and your spouse and f= amily are willing, you can try:
> >>>>>>>>>>>>
> >>>>>>>>>>>> + openwrt sync from h= ead
> >>>>>>>>>>>> + RA spamming filter = stopping mega firewall reloads on comcast ipv6 -
> >>>>>>>>>>>> thx steven barth!
> >>>>>>>>>>>> + switch from dnsmasq= to using odhcpd for ipv6 RAs (thx #openwrt!)
> >>>>>>>>>>>> + Comcast ipv6 actual= ly tested by me
> >>>>>>>>>>>> + GUI is now https - = thx sebastian! (we still have some work left
> >>>>>>>>> here)
> >>>>>>>>>>>> For snowden points, i= t also does perfect forward secrecy.
> >>>>>>>>>>>> + GUI has selectable = skins (pick one, any one)
> >>>>>>>>>>>> + SQM starts correctl= y on boot and other restarts
> >>>>>>>>>>>> + SQM now scales bett= er to higher rates
> >>>>>>>>>>>> + updated on-board do= cumentation ( example:
> >>>>>>>>>>>> http://cero2.bufferbloat.net/cerowrt= /index.html )
> >>>>>>>>>>>> + updated uftp, ccnx,= new libnettle package (for dnsmasq 2.69) - thx
> >>>>>>>>>>>> stephen walker
> >>>>>>>>>>>> + sysupgrade fixed > >>>>>>>>>>>>
> >>>>>>>>>>>> on the minus side
> >>>>>>>>>>>>
> >>>>>>>>>>>> - We still have some = timing problems in picking up the RAs,
> >>>>>>>>>>>> particularly from wif= i.
> >>>>>>>>>>>> If you don't get = ipv6 addresses on your wifi client after a fresh
> >>>>>>>>>>>> boot of cero,
> >>>>>>>>>>>> reconnect the wifi cl= ient. After cero is fully booted. and has
> >>>>>>>>>>>> dhcpv6-pd'd addre= sses, you'll get them. Usually.
> >>>>>>>>>>>>
> >>>>>>>>>>>> - bcp38: didn't g= et 'round2it src/dst routing solves half of it
> >>>>>>>>>>>> - updated shaperprobe= , ditg, same
> >>>>>>>>>>>> - HT40+ DOES appear t= o be NOT working. (this has been the case for a
> >>>>>>>>> while)
> >>>>>>>>>>>> - Hurricane electric = ipv6 tunnels are *badly broken* as in *will
> >>>>>>>>>>>> disable your router* = with a zillion extra processes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> a huge change in open= wrt made saturday was a switch to source
> >>>>>>>>> specific routing,
> >>>>>>>>>>>>
> >>>>>>>>>>>> e.g, if you have two = ipv6 providers, (or a vpn, and so on)
> >>>>>>>>>>>> stuff from source A w= ill go out the right destination for destination
> >>>>>>>>> A,
> >>>>>>>>>>>> and stuff from source= B will go out the right destination for
> >>>>>>>>>>>> destination B. At lea= st in theory.
> >>>>>>>>>>>>
> >>>>>>>>>>>> so you will see "= ;from" routes.
> >>>>>>>>>>>>
> >>>>>>>>>>>> root@cerowrt:~# ip -6= route
> >>>>>>>>>>>> default from :: via f= e80::201:5cff:de41:b841 dev ge00 =A0proto static
> >>>>>>>>> metric 1024
> >>>>>>>>>>>> default from 2001:E:L= :I:D:E:D:Z via fe80::201:5ccf:fe41:b841 dev ge00
> >>>>>>>>>>>> proto static =A0metri= c 1024
> >>>>>>>>>>>> default from 2601:X:Y= ::0::/60 via fe80::201:5ccf:fe41:b841 dev ge00
> >>>>>>>>>>>> proto static =A0metri= c 1024
> >>>>>>>>>>>> 2601:X:Y:0::/64 dev g= w00 =A0proto kernel =A0metric 256 =A0expires 345262sec
> >>>>>>>>>>>> 2601:X:Y:1::/64 dev g= w10 =A0proto kernel =A0metric 256 =A0expires 345262sec
> >>>>>>>>>>>> 2601:X:Y:2::/64 dev s= e00 =A0proto kernel =A0metric 256 =A0expires 345262sec
> >>>>>>>>>>>> 2601:X:Y:3::/64 dev s= w00 =A0proto kernel =A0metric 256 =A0expires 345262sec
> >>>>>>>>>>>> 2601:X:Y:4::/64 dev s= w10 =A0proto kernel =A0metric 256 =A0expires 345262sec
> >>>>>>>>>>>> unreachable 2601:X:X:= 0::/60 dev lo =A0proto static =A0metric 2147483647
> >>>>>>>>> error -128
> >>>>>>>>>>>>
> >>>>>>>>>>>> I figure there is muc= h work to be done to get things like ipsec and
> >>>>>>>>> openvpn
> >>>>>>>>>>>> and bird/quagga/babel= d to work well again, but source/dest routing was
> >>>>>>>>>>>> desparately needed, s= o...
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1] All my testing wa= s done on an ARRIS TM822G cablemodem. (I have a
> >>>>>>>>> profoundly
> >>>>>>>>>>>> low opinion of severa= l other cablemodems, notably the technicolor...)
> >>>>>>>>>>>> There are a few other= testers on other cablemodems, please report
> >>>>>>>>>>>> in...
> >>>>>>>>>>>>
> >>>>>>>>>>>> I return now to my re= gularly scheduled workweek from last wednesday.
> >>>>>>>>>>>> Share and enjoy.
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Dave T=E4ht
> >>>>>>>>>>>>
> >>>>>>>>>>>> Fixing bufferbloat wi= th cerowrt:
> >>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Dave T=E4ht
> >>>>>>>>>>>
> >>>>>>>>>>> Fixing bufferbloat with c= erowrt:
> >>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html
> >>>>>>>>>>> _________________________= ______________________
> >>>>>>>>>>> Cerowrt-devel mailing lis= t
> >>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
> >>>>>>>>>>> https://lists.bufferbloat.net/listi= nfo/cerowrt-devel
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Dave T=E4ht
> >>>>>
> >>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/= subscribe.html
> >>>>
> >>>
> >>> --
> >>> Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se
> >>
> >
> >
> >
> > --
> > Dave T=E4ht
> >
> > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>

--001a11394e6e6248e904f1dd07e4--