[Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Dave Taht]

This is a special release intended only for comcast users with ipv6
capable modems and CMTSes.

NOTE: If you are running any form of tunneling for ipv6 (e.g. hurricane)
do NOT try this release, as it breaks badly.

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

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Dave Taht]

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

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

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Toke Høiland-Jørgensen]

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

How about moving the HTTPS listener to a new port, and keep the http listener on port 81, but having it redirect unconditionally to the new address?

-Toke

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Dave Taht]

On Fri, Jan 24, 2014 at 5:08 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> 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...
>
> How about moving the HTTPS listener to a new port, and keep the http listener on port 81, but having it redirect unconditionally to the new address?

Great, now I gotta know :XX. :). IMHO the temporary pain of your web
browser rewriting urls for you
once, is better than sticking a pair of redirects into the system, but
I could be persuaded otherwise.

It does open the question of "why use a specialized port for
configuration at all"? In an ipv6 world we have
restored e2e connectivity, and that makes it possible for random
arbitrary boxes on your network to be
providing a useful web based service, which is a good thing...

and also, suddenly every device with a web server on it on 80 and 443
is vulnerable, ranging from your printer to your fridge.

Now we can arbitrarily block port 80/433 across ingress to the network
(which I fear is what will happen), or we  can move devices containing
sensitive info to their own port range which can be treated more
sensibly.

So how 81 happened was I went through /etc/services and saw that 81-87
had apparently never been allocated.

A "config port" seemed sane, thus 81 for the adminstration gui, and 80
and 443 for their normal uses. I might argue that there should be an
industry standard for a "config port" that has different behavior than
normal ports, by definition listening only on the local network, for
example... or limiting hop count... this is the sort of behavior that
bind has by default.


>
> -Toke
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Sebastian Moeller]

Hi Dave,


On Jan 24, 2014, at 23:27 , Dave Taht <dave.taht@gmail.com> wrote:

> On Fri, Jan 24, 2014 at 5:08 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> 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...
>> 
>> How about moving the HTTPS listener to a new port, and keep the http listener on port 81, but having it redirect unconditionally to the new address?
> 
> Great, now I gotta know :XX. :). IMHO the temporary pain of your web
> browser rewriting urls for you
> once, is better than sticking a pair of redirects into the system, but
> I could be persuaded otherwise.

	My vote is for sticking to 81 as the current set of users should be able to cope (it is cool that this can also be solved by a redirect, but why create a legacy if not absolutely required ;) ).

> 
> It does open the question of "why use a specialized port for
> configuration at all"?

	I thought you explained already, so that cerowrt's port 80 can still serve webpages to the outside?

> In an ipv6 world we have
> restored e2e connectivity, and that makes it possible for random
> arbitrary boxes on your network to be
> providing a useful web based service, which is a good thing...
> 
> and also, suddenly every device with a web server on it on 80 and 443
> is vulnerable, ranging from your printer to your fridge.

	This is quite scary actually, an ever growing number of rarely updated/security-fixed devices connected to the internet without any preemptive control layer in-between.

> 
> Now we can arbitrarily block port 80/433 across ingress to the network
> (which I fear is what will happen), or we  can move devices containing
> sensitive info to their own port range which can be treated more
> sensibly.

	So why not take the guest and secure concept a bit further for this, devices in guests (or open?) can be reached from the internet, devices in secure only after the user defining a rule explicitly allowing connections on a IP or MAC basis? Now what would be nifty if the router would ask for permission to open a connection to one of the secured devices (either temporarily or persistent) via a third device… But that is a different kettle of fish.

> 
> So how 81 happened was I went through /etc/services and saw that 81-87
> had apparently never been allocated.
> 
> A "config port" seemed sane, thus 81 for the adminstration gui, and 80
> and 443 for their normal uses. I might argue that there should be an
> industry standard for a "config port" that has different behavior than
> normal ports, by definition listening only on the local network, for
> example... or limiting hop count... this is the sort of behavior that
> bind has by default.

	;) 


	On a totally unrelated note: I just tested setting up shapers on multiple interfaces with the GUI, and that seems to work quite well (great work, thanks Toke), it only failed to tear those down again when the additional shapers were either disabled or deleted. If I find time again I will have a look at whether it is possible to make this work reliably enough to expose this capability in the GUI again. Why, because that is a relative easy way to reign in the wifi imbalance between uplink and downlink (shaped to 50000 in each direction I see a much better fairness between up and download as well as much better latency albeit costing half of the bandwidth).

Best Regards
	Sebastian


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

[Cerowrt-devel] side issue, related to the bigger picture surrounding Cerowrt and Bufferbloat.

[dpreed]

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


On Friday, January 24, 2014 5:27pm, "Dave Taht" <dave.taht@gmail.com> said:
 

> and also, suddenly every device with a web server on it on 80 and 443
> is vulnerable, ranging from your printer to your fridge.
 
One of the reasons I like the "Cerowrt project" is that it focuses on fixing the aspects of the Internet plumbing that are due to careless practices like presuming that a printer or fridge will be protected inside a "firewall" and thus need not be designed correctly.
 
It reminds me of the attitude toward safety taken by the Auto Industry prior to Ralph Nader.  (whether you like Nader or not, his point was correct at the time - GM and Ford engineering did not design sufficiently safe cars, and that had a huge social impact that individuals could not cope with).
 
We now have printers and fridges that are "unsafe at any speed", just as we have access networks that are knowingly designed to get bloated under stress, amplifying the stress rather than ameliorating it.
 
Now there may be "temporary kludges" that can protect the printers and fridges thus misdesigned - and NAT firewalls are possibly OK in that light.  But honestly, I want to be able to connect to my printer from anywhere.
 
For a few bucks I can probably build a front-end box for my printer that is a printer server based on encrypted connections (using SSL with certificates, perhaps). E.g. for each printer and fridge, a Raspberry Pi with a USB WiFi interface, connected directly on IPv6. That's about $50 per badly designed consumer electronics device.
 
I'd prefer, however for the printer makers, etc. to make this a standard.  To do so, we need an open source project like Cerowrt to show the way, perhaps starting with the front-end box that implements the standard, since adding software to a printer or fridge itself is hard.
 
 

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

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Jim Reisert AD1C]

On Fri, Jan 24, 2014 at 10:06 AM, Dave Taht wrote:

> I still recomend that everyone on comcast & not running this release do this.

I'm up!

http://test-ipv6.comcast.net/

Your IPv4 address on the public internet appears to be 76.25.42.131

Your IPv6 address on the public internet appears to be
2601:1:8a80:932:bc99:de2f:7f93:455f

Congratulations! You appear to have both IPv4 and IPv6 internet
working. If a publisher publishes to IPv6, your browser will connect
using IPv6. Note: Your browser appears to prefer IPv4 over IPv6 when
given the choice. This may in the future affect the accuracy of sites
who guess at your location.

Your DNS server (possibly run by your ISP) appears to have IPv6 internet access.

-- 
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Dave Taht]

On Sat, Jan 25, 2014 at 11:57 AM, Jim Reisert AD1C
<jjreisert@alum.mit.edu> wrote:
> On Fri, Jan 24, 2014 at 10:06 AM, Dave Taht wrote:
>
>> I still recomend that everyone on comcast & not running this release do this.
>
> I'm up!

And hopefully you'll stay up. :)

> http://test-ipv6.comcast.net/
>
> Your IPv4 address on the public internet appears to be 76.25.42.131
>
> Your IPv6 address on the public internet appears to be
> 2601:1:8a80:932:bc99:de2f:7f93:455f

You will want to lock down some passwords, and restrict access
to your own subnets. One thing not done is any form

> Congratulations! You appear to have both IPv4 and IPv6 internet
> working. If a publisher publishes to IPv6, your browser will connect
> using IPv6. Note: Your browser appears to prefer IPv4 over IPv6 when
> given the choice. This may in the future affect the accuracy of sites
> who guess at your location.

Which browser is this?

> Your DNS server (possibly run by your ISP) appears to have IPv6 internet access.

Excellent. 4 down, several billion to go.


> --
> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Dave Taht]

On Sat, Jan 25, 2014 at 12:09 PM, Dave Taht <dave.taht@gmail.com> wrote:
> On Sat, Jan 25, 2014 at 11:57 AM, Jim Reisert AD1C
> <jjreisert@alum.mit.edu> wrote:
>> On Fri, Jan 24, 2014 at 10:06 AM, Dave Taht wrote:
>>
>>> I still recomend that everyone on comcast & not running this release do this.
>>
>> I'm up!
>
> And hopefully you'll stay up. :)

I just ping6'd you and you were up briefly and not now.

>
>> http://test-ipv6.comcast.net/
>>
>> Your IPv4 address on the public internet appears to be 76.25.42.131
>>
>> Your IPv6 address on the public internet appears to be
>> 2601:1:8a80:932:bc99:de2f:7f93:455f
>
> You will want to lock down some passwords, and restrict access
> to your own subnets. One thing not done is any form

of adding ipv6 to the xined daemon, by default it restricts
access to ipv4 natted hosts only. (so the router is very secure).

I wouldn't mind if you added a line to /etc/xinet.d/netserver
to let me try a rrul test from here:

only_from = 172.16.0.0/12 149.20.63.30 2001:4f8:3:203::c001

(this is the snapon test server)

Commonly insecure ports like windows filesharing are blocked on ipv6
and ipv4 from the public internet, already.

>
>> Congratulations! You appear to have both IPv4 and IPv6 internet
>> working. If a publisher publishes to IPv6, your browser will connect
>> using IPv6. Note: Your browser appears to prefer IPv4 over IPv6 when
>> given the choice. This may in the future affect the accuracy of sites
>> who guess at your location.
>
> Which browser is this?
>
>> Your DNS server (possibly run by your ISP) appears to have IPv6 internet access.
>
> Excellent. 4 down, several billion to go.
>
>
>> --
>> Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us
>
>
>
> --
> 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

Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease

[Jim Reisert AD1C]

On Wed, Jan 22, 2014 at 10:40 AM, Dave Taht wrote:

> I expect luci to work over https. I will give samba a shot but I lack windows.
>
> Sure, let someone else give it a shot first, don't upset the family
> for no reason.

I flashed the router (NOT as an upgrade) and things came up rather quickly.

Then I needed Dave's help...  We spoke for over an hour on Skype.

First we turned SQM on and Dave helped me get the right set of for
upload and download speed.  Latency was very good.

After installing Samba, we could not see the remote Windows file
shares over the network, except by using the TCP/IP v4 numerical
address. Suspecting it was a WINS problem, I changed the setting on
both my network adapters (local and remote):

<network adapter> | Properties
Click on TCP/IPv4 and then on Properties
Clicked Advanced button at the bottom, then go to the WINS tab

I had "Enable NetBIOS over TCP/IP" checked on both computers. I
changed this to the Default setting (use NetBIOS setting from the DHCP
server).  After another reboot, the Windows networking was working by
name.

The "wired" computer doesn't appear to be broadcasting its name over
the network, i.e. it doesn't immediately show up when browsing the
network on the "wireless" machine, but it can be accessed by name,
i.e. \\<machine> so that's good enough to get things going for me
again.

Thanks to Dave for all the help, he might post some of the graphs he
made for me this morning.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us