[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 at gmail.com> wrote:

> On Fri, Jan 24, 2014 at 5:08 PM, Toke Høiland-Jørgensen <toke at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel