From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A21E321F207 for ; Sat, 8 Feb 2014 02:35:27 -0800 (PST) Received: from hms-beagle.home.lan ([217.86.112.208]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MGAdz-1VxZJz2MSd-00FAcZ for ; Sat, 08 Feb 2014 11:35:24 +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: Sat, 8 Feb 2014 11:35:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E4E8B6F-40B6-47B8-9A3B-D99189497629@gmx.de> 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:/Why/0U1YJ0Mk5twvIBen71F1gnMuqhglpPd0Tf0SAVCbbsCtyi fg+383FjmG10xK8s/XhkqdldO/9t3F/xxlHHc1YIOhZLpcoyyhIzhu+rMb8FYu2AeqehE6g 4hEQkxDZkYoIKxWzvvMPg0ffg9PZSQMlYqVnIxicLUd5Bzz6ls46ZR8fim68t4Uv2x4ENCi tx+UYqsD0M2F/cb6JsPKg== 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 10:35:28 -0000 Hi Dave, On Feb 8, 2014, at 04:52 , Dave Taht wrote: >=20 > 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. =46rom the linux machine sitting = in cero's se00 subnet, neither of these work. > The more correct test is -s my se00 address. =46rom the linux machine: happy-horse:~ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 28:92:4A:30:5D:BE =20 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:320829008 errors:0 dropped:0 overruns:0 frame:0 TX packets:166168903 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000=20 RX bytes:469076940313 (447346.6 Mb) TX bytes:21392778864 = (20401.7 Mb) Interrupt:18=20 happy-horse:~ # traceroute -s 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe = ipv6.google.com traceroute to ipv6.google.com (2607:f8b0:4007:804::1003), 30 hops max, = 80 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * happy-horse:~ #=20 So that does not lead anywhere... >=20 > Which doesn't have an address in your paste below. Sorry or not including it before; by the way is my assumption = correct that happy-horse's global ip6 is = 2003:6b:f2a:9c01:2a92:4aff:fe30:5dbe at least 2003:6b:f2a:9c0 is the = prefix my telekom router distributes on its internal interfaces and = 30:5dbe is part of happy-horse's mac address. Best Regards Sebastian >=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 > > > > > > > > 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.764 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. > > >>>> > > >>>> =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) > > >>>> > > >>>> 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 = 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/b618ad5373ae619e3d01a49f2c672a8cc1dc= 59a6 > > >>>> > > >>>> 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 = > > >>>>>>>>> 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=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 > >