[Cerowrt-devel] Fwd: ipv6 over DT

[Cerowrt-devel] Fwd: ipv6 over DT

[Sebastian Moeller]

This was taken private, but probably could be of interest to other users, so on Dave's request:

Begin forwarded message:

> From: Sebastian Moeller <moeller0@gmx.de>
> Subject: Re: ipv6 over DT
> Date: February 7, 2014 19:01:43 GMT+01:00
> To: Dave Taht <dave.taht@gmail.com>
> Cc: Mikael Abrahamsson <swmike@swm.pp.se>
> 
> 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 <dave.taht@gmail.com> wrote:
> 
>> Changing the title of this thread as it's forked 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 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 <swmike@swm.pp.se> 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" <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.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 <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 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" <moeller0@gmx.de> wrote:
>>>>>>> Hi Dave,
>>>>>>> 
>>>>>>> 
>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <dave.taht@gmail.com> 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 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
>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Mikael Abrahamsson    email: swmike@swm.pp.se
>>> 
>> 
>> 
>> 
>> -- 
>> Dave Täht
>> 
>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> 

Re: [Cerowrt-devel] ipv6 over DT

[Sebastian Moeller]

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

	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.



> 
> (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 <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
>>    inet6 ::1/128 scope host
>>       valid_lft forever preferred_lft forever
>> 2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
>>       valid_lft forever preferred_lft forever
>> 3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 32
>>    inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link
>>       valid_lft forever preferred_lft forever
>> 14: gw11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a221:b7ff:feb9:5c24/64 scope link
>>       valid_lft forever preferred_lft forever
>> 15: gw01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a221:b7ff:feb9:5c22/64 scope link
>>       valid_lft forever preferred_lft forever
>> 16: sw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a021:b7ff:feb9:5c24/64 scope link
>>       valid_lft forever preferred_lft forever
>> 17: sw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
>>       valid_lft forever preferred_lft forever
>> 18: gw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>>    inet6 fe80::a421:b7ff:feb9:5c22/64 scope link
>>       valid_lft forever preferred_lft forever
>> 19: gw10: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <LOOPBACK,UP,LOWER_UP> mtu 65536
>>    inet6 ::1/128 scope host
>>       valid_lft forever preferred_lft forever
>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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=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 <dave.taht@gmail.com> wrote:
>>>> 
>>>>> Changing the title of this thread as it's forked 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 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 <swmike@swm.pp.se> 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" <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.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 <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 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" <moeller0@gmx.de> wrote:
>>>>>>>>>> Hi Dave,
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <dave.taht@gmail.com> 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 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
>>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Mikael Abrahamsson    email: swmike@swm.pp.se
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Dave Täht
>>>>> 
>>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>>>> 
>>> 
>>> --
>>> Mikael Abrahamsson    email: swmike@swm.pp.se
>> 
> 
> 
> 
> -- 
> Dave Täht
> 
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] ipv6 over DT

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 28966 bytes --]

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
>
>         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 <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
> >>    inet6 ::1/128 scope host
> >>       valid_lft forever preferred_lft forever
> >> 2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 32
> >>    inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 14: gw11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a221:b7ff:feb9:5c24/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 15: gw01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a221:b7ff:feb9:5c22/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 16: sw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a021:b7ff:feb9:5c24/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 17: sw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 18: gw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> >>    inet6 fe80::a421:b7ff:feb9:5c22/64 scope link
> >>       valid_lft forever preferred_lft forever
> >> 19: gw10: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <LOOPBACK,UP,LOWER_UP> mtu 65536
> >>    inet6 ::1/128 scope host
> >>       valid_lft forever preferred_lft forever
> >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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=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 <dave.taht@gmail.com> wrote:
> >>>>
> >>>>> Changing the title of this thread as it's forked 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 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 <swmike@swm.pp.se>
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" <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.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 <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 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" <moeller0@gmx.de>
wrote:
> >>>>>>>>>> Hi Dave,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <dave.taht@gmail.com>
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 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
> >>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
> >>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mikael Abrahamsson    email: swmike@swm.pp.se
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Dave Täht
> >>>>>
> >>>>> Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
> >>>>
> >>>
> >>> --
> >>> Mikael Abrahamsson    email: swmike@swm.pp.se
> >>
> >
> >
> >
> > --
> > Dave Täht
> >
> > Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html
>

[-- Attachment #2: Type: text/html, Size: 47971 bytes --]

Re: [Cerowrt-devel] ipv6 over DT

[Sebastian Moeller]

Hi Dave,


On Feb 8, 2014, at 04:52 , Dave Taht <dave.taht@gmail.com> wrote:

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

	From the linux machine:
happy-horse:~ # ifconfig eth0
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:320829008 errors:0 dropped:0 overruns:0 frame:0
          TX packets:166168903 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:469076940313 (447346.6 Mb)  TX bytes:21392778864 (20401.7 Mb)
          Interrupt:18 

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:~ # 

So that does not lead anywhere...


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

> 
> >
> >
> > >
> > > (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 <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
> > >>    inet6 ::1/128 scope host
> > >>       valid_lft forever preferred_lft forever
> > >> 2: se00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 3: ge00: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 32
> > >>    inet6 fe80::8c4d:74ff:feea:d5e9/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 14: gw11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a221:b7ff:feb9:5c24/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 15: gw01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a221:b7ff:feb9:5c22/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 16: sw10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a021:b7ff:feb9:5c24/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 17: sw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a021:b7ff:feb9:5c22/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 18: gw00: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
> > >>    inet6 fe80::a421:b7ff:feb9:5c22/64 scope link
> > >>       valid_lft forever preferred_lft forever
> > >> 19: gw10: <BROADCAST,MULTICAST,UP,LOWER_UP> 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: <LOOPBACK,UP,LOWER_UP> mtu 65536
> > >>    inet6 ::1/128 scope host
> > >>       valid_lft forever preferred_lft forever
> > >> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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=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 <dave.taht@gmail.com> wrote:
> > >>>>
> > >>>>> Changing the title of this thread as it's forked 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 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 <swmike@swm.pp.se> 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" <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.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 <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 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" <moeller0@gmx.de> wrote:
> > >>>>>>>>>> Hi Dave,
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <dave.taht@gmail.com> 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 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
> > >>>>>>>>>>> Cerowrt-devel@lists.bufferbloat.net
> > >>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Mikael Abrahamsson    email: swmike@swm.pp.se
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Dave Täht
> > >>>>>
> > >>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> > >>>>
> > >>>
> > >>> --
> > >>> Mikael Abrahamsson    email: swmike@swm.pp.se
> > >>
> > >
> > >
> > >
> > > --
> > > Dave Täht
> > >
> > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
> >