From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id D0CDE21F1B9 for ; Fri, 7 Feb 2014 10:46:16 -0800 (PST) Received: from hms-beagle.home.lan ([217.86.112.208]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LjZEm-1VeyX00MDA-00bZIo for ; Fri, 07 Feb 2014 19:46:14 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Fri, 7 Feb 2014 19:46:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DA7F25C-4877-43C5-8069-FEBE2728281F@gmx.de> <954DF955-F94C-4392-83D6-AD21C05C189F@gmx.de> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:YdvOtVwosaqL9yW2clTZ0GvrCn50pZWzKvC85Fj+rRy8SjPXwZd xADiwaqw35So/GplVWlBit41VEb63crjKglfdqhSHzuNDRcZ4xBVZUtSvDpu5L24PI1FcI3 BAyfwa6sk//R3bJv8o5Tprk3FdG9ykVsOh0TZX9CMusEDNMmDt8oLFBNFNubgSsH4HsOQsg wx3BzISaufSW9MN+XHhow== 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: Fri, 07 Feb 2014 18:46:17 -0000 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. =46rom the linux machine sitting in cero's se00 subnet, = neither of these work. >=20 > (and take this public please, I'm terribly buried right now) Oops, sorry Dave. I will try to keep this public. Best Regards sebastian >=20 > On Fri, Feb 7, 2014 at 1:16 PM, Sebastian Moeller = wrote: >> Hi Mikael, >>=20 >> On Feb 7, 2014, at 19:11 , Mikael Abrahamsson = wrote: >>=20 >>>=20 >>> What does "ip -6 a l" and "ip -6 r l" say? >>=20 >> 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 >>=20 >>=20 >> 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 >>=20 >>=20 >> 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 >>=20 >>=20 >> 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:~> >>=20 >>=20 >>>=20 >>> I'm nostly interested in if there is a route for the delegated = prefix or if DHCPv6-PD failed. >>=20 >> What is your verdict, based on the information above? >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=20 >>> On Fri, 7 Feb 2014, Sebastian Moeller wrote: >>>=20 >>>> Hi Dave, >>>>=20 >>>> small update... >>>>=20 >>>> 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.764 ms >>>>=20 >>>> --- 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 >>>>=20 >>>>=20 >>>> 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 >>>>=20 >>>> 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 >>>>=20 >>>> --- ipv6.l.google.com ping6 statistics --- >>>> 1 packets transmitted, 0 packets received, 100.0% packet loss >>>>=20 >>>> So somehow what used to be the default gateway under ip4 seems to = be misconfigured... >>>>=20 >>>>=20 >>>> On Feb 6, 2014, at 22:06 , Dave Taht wrote: >>>>=20 >>>>> Changing the title of this thread as it's forked something = incredible. >>>>>=20 >>>>> On Thu, Feb 6, 2014 at 2:41 PM, Sebastian Moeller = wrote: >>>>>> Hi Mikael, >>>>>>=20 >>>>>> thank you so much. I got a bit further, by enabling relaying I = now routinely get IP6 addresses on the connected machines. >>>>>=20 >>>>>> 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). >>>>>=20 >>>>> 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. >>>>=20 >>>> =46rom = 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) >>>>=20 >>>> Router Advertisement & DHCPv6 >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Example configuration section (/etc/config/dhcp) >>>>=20 >>>> config dhcp lan >>>> option dhcpv6 hybrid >>>> option ra hybrid >>>> option ndp hybrid >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> Still, there should be a way to correctly configure ND proxying in = a >>>>> multi-lan environment in the base system with odhcpd. >>>>=20 >>>> I think the "option ndp 'something'" are missing in 3.10.28-1, = the version I am still using... >>>>=20 >>>>> I think looking >>>>> at the original openwrt configuration for such might be = productive. >>>>=20 >>>> Good idea, I will try my luck and report back if there is = anything new. >>>>=20 >>>>>=20 >>>>> But it is still not the correct way to get /60s. It's not clear to = me >>>>> if DT is using 6rd or not. >>>>=20 >>>> 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) >>>>=20 >>>> Does that tell you anything? >>>>=20 >>>>=20 >>>>>=20 >>>>> 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 >>>>>=20 >>>>> https://www.tunnelbroker.net/forums/index.php?topic=3D2293.0 >>>>>=20 >>>>> And this reports it broken. >>>>>=20 >>>>> = http://www.dslreports.com/forum/r28530086-AT-T-now-blocking-IPv6-tunnels >>>>>=20 >>>>> I have ordered a ipv6 capable dsl box for the one AT&T based = network I >>>>> have access to. >>>>>=20 >>>>> 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. >>>>=20 >>>> interesting, I have not tried a tunnel yet (and would prefer to = avoid that since native ip6 seems just a grasp away ;) ) >>>>=20 >>>>>=20 >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> ip -6 route show would help on the cero box and the host. >>>>=20 >>>> 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 >>>>=20 >>>> 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 >>>>=20 >>>> 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 >>>>=20 >>>> happy-horse cannot ping6 : >>>> moeller@happy-horse:~> ping6 -c1 ipv6.google.com >>>> PING ipv6.google.com(lax04s08-in-x00.1e100.net) 56 data bytes >>>>=20 >>>> --- ipv6.google.com ping statistics --- >>>> 1 packets transmitted, 0 received, 100% packet loss, time 0ms >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> No kidding. >>>>=20 >>>> It looks like somethings got just fixed in odhcpd that might be = relevant: >>>> = https://github.com/sbyx/odhcpd/commit/b618ad5373ae619e3d01a49f2c672a8cc1dc= 59a6 >>>>=20 >>>> 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... >>>>=20 >>>>>=20 >>>>>> Getting information "straight from the horse's mouths" obviously = would be really great. >>>>>=20 >>>>> We'll get it sorted as time allows. Exciting times! >>>>=20 >>>> 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 = ;) ) >>>>=20 >>>> Best Regards >>>> Sebastian >>>>=20 >>>>>=20 >>>>>> Thanks for you help >>>>>> Best Regards >>>>>> Sebastian >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Feb 6, 2014, at 15:14 , Mikael Abrahamsson = wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> I forwarded this internally but I have yet to receive a = response. I'll ping them again. >>>>>>>=20 >>>>>>> On Sun, 26 Jan 2014, Dave Taht wrote: >>>>>>>=20 >>>>>>>> I don't know a lot about DT and their ipv6 support. >>>>>>>>=20 >>>>>>>> It sounds like they are not using dhcpv6pd, or there is some = other option >>>>>>>> you need to supply. >>>>>>>>=20 >>>>>>>> Perhaps Mikael (ccd) knows. >>>>>>>> On Jan 26, 2014 3:42 PM, "Sebastian Moeller" = wrote: >>>>>>>>=20 >>>>>>>>> Hi Dave, >>>>>>>>>=20 >>>>>>>>> so 3.10.28-1 seems to work quite well (if I do not jinx = anything by saying >>>>>>>>> after only 1 hour testing ;) ). >>>>>>>>>=20 >>>>>>>>> Doing: >>>>>>>>> ./netperf-wrapper -l 60 -H gw.home.lan rrul -p all_scaled = -disable-log -t >>>>>>>>> hms-beagle_cerowrt3.10.21-1_2_nacktmulle >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> But this is not changed. Unaligned instructions are still at = 0, by the way. >>>>>>>>>=20 >>>>>>>>> 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 >>>>>>>>>=20 >>>>>>>>> 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! >>>>>>>>>=20 >>>>>>>>> Do you, by chance know what I did wrong? (Or is a /64 too = little?) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> best regards >>>>>>>>> Sebastian >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Jan 26, 2014, at 20:15 , Dave Taht = wrote: >>>>>>>>>=20 >>>>>>>>>> Yea I think it was 2. >>>>>>>>>>=20 >>>>>>>>>> I have been running with 1 to no messages thanks for looking = it up. :-) >>>>>>>>>>=20 >>>>>>>>>> I put out a 3.10.28-1 today in the comcast subdir. >>>>>>>>>>=20 >>>>>>>>>> Ssh... Don't tell anyone. >>>>>>>>>>=20 >>>>>>>>>> Toatally untested has all the procd work to date in it = although I may >>>>>>>>> have goofed on rngd.... >>>>>>>>>>=20 >>>>>>>>>> Getting on a plane in 2 hrs. >>>>>>>>>>=20 >>>>>>>>>> On Jan 26, 2014 1:42 PM, "Sebastian Moeller" = wrote: >>>>>>>>>> Hi Dave, >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht = wrote: >>>>>>>>>>=20 >>>>>>>>>>> On Tue, Jan 21, 2014 at 3:59 PM, Dave Taht = >>>>>>>>> wrote: >>>>>>>>>>>> This is a special release intended only for comcast users = with ipv6 >>>>>>>>>>>> capable modems and CMTSes. >>>>>>>>>>>=20 >>>>>>>>>>> There have been several testers getting back to me = privately. All >>>>>>>>> report >>>>>>>>>>> good results IF you reflash from scratch. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>>=20 >>>>>>>>>>> option sourcerouting '0' >>>>>>>>>>>=20 >>>>>>>>>>> The bug is also specific to cerowrt. the openwrt folk report = it works >>>>>>>>> for them. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> Finding these last instruction traps is going to be a PITA. = Can I >>>>>>>>> encourage >>>>>>>>>>> people to add this to their config? >>>>>>>>>>>=20 >>>>>>>>>>> echo 1 > /sys/kernel/debug/mips/unaligned_action >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>> echo 2 > /sys/kernel/debug/mips/unaligned_action >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>> Best Regards >>>>>>>>>> Sebastian >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> and check their logfile once in a while, perhaps we can = isolate where >>>>>>>>> and >>>>>>>>>>> why it happens. >>>>>>>>>>>=20 >>>>>>>>>>> I went to town last night adding procd support to various = easy daemons, >>>>>>>>>>> it gets simpler after the first 3... >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>> = http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/comcast/3.10.26-7/ >>>>>>>>>>>>=20 >>>>>>>>>>>> I strongly recommend all cerowrt users on comcast, = upgrade.[1] >>>>>>>>>>>>=20 >>>>>>>>>>>> If you are on comcast and dare not upgrade to this, comment = out these >>>>>>>>>>>> lines in /etc/config/network >>>>>>>>>>>>=20 >>>>>>>>>>>> #config interface ge01 # wan6 on some release. >>>>>>>>>>>> # option ifname @ge00 >>>>>>>>>>>> # option proto dhcpv6 >>>>>>>>>>>> # option 'broadcast' '1' >>>>>>>>>>>> # option 'metric' '2048' >>>>>>>>>>>> # option 'reqprefix' '60' >>>>>>>>>>>>=20 >>>>>>>>>>>> and reboot to disable dhcpv6 on the external interface = entirely. >>>>>>>>>>>=20 >>>>>>>>>>> I still recomend that everyone on comcast & not running this = release >>>>>>>>> do this. >>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> = http://snapon.lab.bufferbloat.net/~d/bev/comcast_native_ipv6/ >>>>>>>>>>>>=20 >>>>>>>>>>>> Oh brave new world that may have new protocols in it. >>>>>>>>>>>>=20 >>>>>>>>>>>> A bunch of other stuff landed in cero, and if you are not = tunneling, >>>>>>>>>>>> and your spouse and family are willing, you can try: >>>>>>>>>>>>=20 >>>>>>>>>>>> + 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 >>>>>>>>>>>>=20 >>>>>>>>>>>> on the minus side >>>>>>>>>>>>=20 >>>>>>>>>>>> - 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> - 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> a huge change in openwrt made saturday was a switch to = source >>>>>>>>> specific routing, >>>>>>>>>>>>=20 >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> so you will see "from" routes. >>>>>>>>>>>>=20 >>>>>>>>>>>> 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 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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... >>>>>>>>>>>>=20 >>>>>>>>>>>> [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... >>>>>>>>>>>>=20 >>>>>>>>>>>> I return now to my regularly scheduled workweek from last = wednesday. >>>>>>>>>>>> Share and enjoy. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- >>>>>>>>>>>> Dave T=E4ht >>>>>>>>>>>>=20 >>>>>>>>>>>> Fixing bufferbloat with cerowrt: >>>>>>>>> http://www.teklibre.com/cerowrt/subscribe.html >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Dave T=E4ht >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Dave T=E4ht >>>>>=20 >>>>> Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html >>>>=20 >>>=20 >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html