This was taken private, but probably could be of interest to other users, so on Dave's request:
Begin forwarded message: > From: Sebastian Moeller <[email protected]> > Subject: Re: ipv6 over DT > Date: February 7, 2014 19:01:43 GMT+01:00 > To: Dave Taht <[email protected]> > Cc: Mikael Abrahamsson <[email protected]> > > 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=0 ttl=57 time=70.764 ms > > --- ipv6.google.com ping statistics --- > 1 packets transmitted, 1 packets received, 0% packet loss > round-trip min/avg/max = 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=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> 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=40+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 <[email protected]> wrote: > >> Changing the title of this thread as it's forked something incredible. >> >> On Thu, Feb 6, 2014 at 2:41 PM, Sebastian Moeller <[email protected]> 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=2293.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 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 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/b618ad5373ae619e3d01a49f2c672a8cc1dc59a6 > > 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 <[email protected]> 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" <[email protected]> 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=0x00e! >>>>>> 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 <[email protected]> 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" <[email protected]> wrote: >>>>>>> Hi Dave, >>>>>>> >>>>>>> >>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <[email protected]> wrote: >>>>>>> >>>>>>>> On Tue, Jan 21, 2014 at 3:59 PM, Dave Taht <[email protected]> >>>>>> 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 source >>>>>> 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 for >>>>>>>>> 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äht >>>>>>>>> >>>>>>>>> Fixing bufferbloat with cerowrt: >>>>>> http://www.teklibre.com/cerowrt/subscribe.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dave Täht >>>>>>>> >>>>>>>> Fixing bufferbloat with cerowrt: >>>>>> http://www.teklibre.com/cerowrt/subscribe.html >>>>>>>> _______________________________________________ >>>>>>>> Cerowrt-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Mikael Abrahamsson email: [email protected] >>> >> >> >> >> -- >> Dave Täht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
