From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5133F2021DD for ; Fri, 24 Jan 2014 15:15:03 -0800 (PST) Received: from hms-beagle-3.home.lan ([217.86.112.208]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mg3h3-1VuviA3Ojd-00NQEb for ; Sat, 25 Jan 2014 00:14:59 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 25 Jan 2014 00:14:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3851CAD6-7C18-49EE-A4FB-34F9E5BC8E7F@gmx.de> References: <13b6a42d-47ca-4b1b-b3e8-a7ae8ba0809f@email.android.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:0hMUU1WByMJwYDgAnp4oua49+O8owjH8WmnU4F1JwqEnjoz5tiS ++SkK2QRRvK6CswD6zQm0ESjdhAkDd52gvKxefblQAd+ZdoxL8nnaMteOZgRgMZhMwD7kvo mAAFBASz8KjREBrI9AQSFNNGHjOAFL9cDD7JYdXZOR1mf5/eKcKHccqYZjATEASgqpdt925 ZwTe/Micxg3DpNPFFYQ7g== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Comcast specific Cerowrt-3.10.26-7: another "too exciting for me" unrelease X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 23:15:03 -0000 Hi Dave, On Jan 24, 2014, at 23:27 , Dave Taht wrote: > On Fri, Jan 24, 2014 at 5:08 PM, Toke H=F8iland-J=F8rgensen = 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. >>>=20 >>> remember: https://gw.home.lan:81 from now on... >>=20 >> 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? >=20 > 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 ;) ). >=20 > 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... >=20 > 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. >=20 > 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=85 = But that is a different kettle of fish. >=20 > So how 81 happened was I went through /etc/services and saw that 81-87 > had apparently never been allocated. >=20 > 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. ;)=20 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 >=20 >=20 >>=20 >> -Toke >>=20 >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > 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