[Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease
dave.taht at gmail.com
Fri Jan 24 12:06:12 EST 2014
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,
unlike apache, doesn't give any sign as to why the connection is
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
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
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...
> I strongly recommend all cerowrt users on comcast, upgrade.
> 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.
> 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...
>  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
> 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
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel