From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (unknown [66.167.227.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F344C3B2F8; Fri, 11 Mar 2016 15:40:20 -0500 (EST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id u2BKe7rW011640; Fri, 11 Mar 2016 12:40:07 -0800 Date: Fri, 11 Mar 2016 12:40:07 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Alan Jenkins cc: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, bufferbloat-fcc-discuss , "cerowrt-devel@lists.bufferbloat.net" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1304588586-1457728817=:12403" Subject: Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 11 Mar 2016 20:40:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1304588586-1457728817=:12403 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 11 Mar 2016, Alan Jenkins wrote: > On 11/03/2016, Jonathan Morton wrote: >> >>> On 11 Mar, 2016, at 20:22, Luis E. Garcia wrote: >>> >>> Time to start building our own. >> >> A big project in itself - but perhaps a worthwhile one. We wouldn’t be able >> to compete on price against the Taiwanese horde, but price is not the only >> market force on the table. Firmware quality is a bit abstract and nebulous >> to sell to ordinary consumers, but there is one thing that might just get >> their attention. >> >> Making the damned thing easier to configure. >> >> Almost every router now on the market is a blank box with some ports on the >> back, some antennas on top and some lights on the front. If you’re lucky, >> there’ll be a button for WPS (which most consumers would still need to read >> the manual to figure out how to use, and most tinkerers would turn right >> off) and maybe one or two “feature switches”; my Buffalo device has one >> which does “something” to the QoS setup in the stock firmware, and nothing >> at all in OpenWRT. >> >> The lights only tell you that “something is happening” and occasionally >> “something is wrong”, and are invariably cryptic. For example, a green >> flashing light can mean “it’s setting up but not working yet” or “it’s >> working and passing traffic right now”, often on the same light! A critical >> error, such as a cable not plugged in, is often signified only by the >> *absence* of one of the several normal lights, which is invisible to the >> untrained eye. >> >> To actually configure it, you must first connect a computer to it and point >> a Web browser at the right (usually numeric) URL. This URL varies between >> vendors and models, and sometimes even between firmware revisions; the only >> infallible way to determine it is to delve into the configuration that DHCP >> handed out. Also, many routers setup a 'standard' name you can go to, so you don't have to do it by IP. But this can be dealt with by adding a QR code or NFC method to get at a basic configuration. >> You and I can cope with that, but we want something better, and >> less-technical people *need* something better if they are to trust their >> equipment enough to start actually learning about it. I don't know if you really can simplify the configuration the way you are wanting to, but I'd say give it a try. Take OpenWRT and make a configuration program that you think is better. You even have a nice browser based tool to start with (luci). If you can make a browser based tool work well, then if your tool is better/easier, it can be widely used, or you can then try hardware versions of it. >> As a starting point, suppose we build a small display into the case, and >> invite the user to temporarily plug a keyboard, console controller or even a >> mouse directly into the USB port (which most routers now have) to do the >> setup? No Web browser required, and no potentially-vulnerable web server on >> the device either. There are very good reasons why browser setups have replaced built-in displays. There's a limit to how much you can show on a built-in display, and you have to be able to see the display. Not everyone positions their wifi where they can easily see it, let alone plug it into a TV. The best place for a router to sit is usually not the easiest place to see or get at it. You have a much larger display, which gives you room for help text and images, not just a handful of characters. A display is nicer than just LEDs, but it's also a lot more expensive. I also don't like large glowing displays on devices. I frequently put tape over the LEDs to tone things down as well (especially in bedrooms) David Lang >> When not in config mode, the input device can be disconnected and returned >> to its primary role, and the display can offer status information in a >> human-readable format; an RGB-controlled backlight would be sufficient for >> at-a-glance is-everything-okay checks (which is all Apple gives you without >> firing up their proprietary config software on a connected computer). Some >> high-end router models provide just this, without leveraging the possibility >> of easier setup. >> >> - Jonathan Morton > > IMO they already glow quite enough. Better to invest in the software :P. > > Alan > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --680960-1304588586-1457728817=:12403--