[Cerowrt-devel] ipv6 over DT
Sebastian Moeller
moeller0 at gmx.de
Fri Feb 7 13:46:12 EST 2014
Hi Mikael, hi Dave,
On Feb 7, 2014, at 19:33 , Dave Taht <dave.taht at 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 at gmx.de> wrote:
>> Hi Mikael,
>>
>> On Feb 7, 2014, at 19:11 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:
>>
>>>
>>> What does "ip -6 a l" and "ip -6 r l" say?
>>
>> On cerowrt:
>> root at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at gmx.de> wrote:
>>>>>>>>>> Hi Dave,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Jan 24, 2014, at 18:06 , Dave Taht <dave.taht at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Tue, Jan 21, 2014 at 3:59 PM, Dave Taht <dave.taht at 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 at 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 at lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mikael Abrahamsson email: swmike at swm.pp.se
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dave Täht
>>>>>
>>>>> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
>>>>
>>>
>>> --
>>> Mikael Abrahamsson email: swmike at swm.pp.se
>>
>
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel
mailing list