Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, 12 Mar 2016, Wayne Workman wrote: @David lang, Dude, Help make it happen. I don't know all the details. I don't even pretend to know anything about IC design and manufacturing. Look if we want a platform that is open, then it'll be an open source chipset. Yes, the first of its kind. We need someone who is willing to do this in their free time(as you said), or a company that is willing to be paid to do it. We can be pioneers. We CAN be pioneers. All we have to do is figure this out. It's been done before, with the Linux kernel. It can be done again. The person who has made a chipset in their free time is out there. Let's find them! I'll be happy to support anyone who tackles this. But your question was if something like this was a good use of 'our money'. If you are talking the bufferbloat team, make-wifi-fast team, or even team trying to convince teh FCC nto to outlaw OpenWRT, then no, funding the development of a chipset from scratch is not a good use of 'our money', it will have no effect for several years (by which time we may be looking at the next chipset), and we don't have anywhere close to the funding needed to pull it off. I would do us no good to create a fully open chip if the FCC mandates that the firmware must be locked down. Would I like someone to do this, Sure. I'll contribute towards a kickstarter, even if it's $100 for a mini-pci card that is the equivalent of what we can get today for $30, but it would take tens of thousands of people doing that to fund the project, and I have serious doubts if you can get that much funding for something with such a long lead time. If someone does the research and puts together a FPGA version that works and is looking for funding to convert it to a ASIC, I think you could get funding. But that's not the question in front of us now. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] Communicating better about bloat/openwrt/our issues over the web
On Sun, Mar 6, 2016 at 5:48 PM, Dave Taht wrote: > > Let me open the question - how do we get more people interested in > reading/writing about open firmware, bufferbloat, modded routers, > embedded boards, fighting with the FCC, etc? > Not sure if that is possible... Wiki is a source of information, and only if becomes place with "best of internet" or "only place on internet" for some info then it will get used more. First step - fixing serch - http://www.bufferbloat.net/search?q=test Second step - I'm not user of this wiki, so who ever it is shouls expose best wiki pages to front. Thirs step - check web server logs for what search term google brings people to this wiki and make those pages awesome. Fourt step - profit :) ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] routers you can throw off the back of a truck
On Fri, Jan 22, 2016 at 8:11 AM, moeller0 wrote: > Hi Valent, > > > On Jan 22, 2016, at 07:37 , Jonathan Morton > wrote: > > > > > >> On 22 Jan, 2016, at 01:40, Valent Turkovic > wrote: > >> > >> Jonathan do you know why cake doesn't compile for mips platform? > >> How do you test Cake? Do you use OpenWrt or some other platform? > >> Can anyone help to get Cake compiled on OpenWrt? > > > > The bug report is several months old. Cake has been developed and > cleaned up significantly since then. It’s a shame the log didn’t include > the lines immediately *preceding* “some warnings being treated as errors”. > > > > I myself test by compiling against a recent net-next kernel on x86 and > ppc32, and an Ubuntu kernel (which is significantly older) on amd64. I do > have a mips router and some armv6/7 units as well, but I haven’t actively > been using them for testing - it shouldn’t be any harder to get it running > *just* because it’s mips, though. > > I believe Kevin Darbyshire-Bryant created a nice how-to for > including cake into a recent openwrt firmware (see last section of > http://www.bufferbloat.net/projects/codel/wiki/Cake ) which I believe > works well. So well actually that I believe both Arokh’s ( > https://forum.openwrt.org/viewtopic.php?id=50914 ) as well Hnyman’s ( > https://forum.openwrt.org/viewtopic.php?id=28392 ) community builds now > include cake (not sure whether they contain the most recent cake though) so > it could be as si ole as just flashing one of their pre-compiled firmwares > and get into testing almost immediately. > > Thanks Sebastian, I have been doing battle on other fronts (hardware for MeshPoint) and now finally got back to dealing with cake... I'll try instructions, they look pretty straight forward. What is the reason why cake in still not included by default in latest trunk? It would make testing much easier for wider number of people... Cheers, Valent. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] On building your own routers and the mass market
On Sat, 12 Mar 2016, Outback Dingo wrote: ... and I'm going to order a couple, 'cause their wifi is not as good as it could be (nobody's is), and he said I could visit periodically with make-wifi-fast's upcoming fixes. https://eero.com/ the cznic team has already done this. https://omnia.turris.cz/en/ Looks like a nice device, though can you buy one now, or is this another smoke and mirrors, they did get a ton of funding. now lets see if they deliver. Can you source the devices now? No, they are not shipping yet, but they are expecting to start delivering them next month (April 2016) They have several thousand to deliver based on existing orders. David Lang___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
> On 13 Mar, 2016, at 02:15, David Lang wrote: > > my point is that you can use a browser interface to mock-up what you would do > on your local display without having to build custom hardware. Yes, it would > mean you have to work with javascript/etc to build this mockup, but it would > let you create a bitmap image with buttons/etc that will work the same way > that your physical device would, but be able to tinker with things that would > require hardware changes if it was a physical device (different screen sizes, > button placements, etc) And my point is that if I can do that *without* involving a browser, so much the better. Given my existing experience, I can probably do it *easier* in something like C and Xlib (yes, really) than in a browser. Yes, it would be a pure software mockup, and thus still easy to change. > a 6x8 font on a 2.7" screen is unreadable for many people, this is about an > 11pt font on something that is not at your optimum reading distance. The display I linked has basically the same pixel density as a 1980s/1990s Macintosh display, a 9-pin dot-matrix printer, and a basic Nokia phone - the standard 72dpi. Anyone with standard visual acuity should be able to read 8-pixel-high text on it. Your concern would be limited to that segment of the population who already needs to buy large-print books and newspapers. The most important text wouldn’t be 6x8 - I included that stat only to contrast it with the 16x2 cell text-only display. Since it’s a graphical display, we can use larger fonts where desired. Incidentally, the classic Nokia phones seem to use a proportional font which is 5x7 on average. They sold many millions, probably because they designed a UI that even my mother could be coached into learning (believe me, that’s a feat). Up, down, select, cancel, and a numeric keypad. The size of the text on the screen doesn’t seem to have been a factor. > OLEDs do color as well. The ones that do colour are even more expensive than the mono ones. Increasing the size of an OLED display also seems to be incredibly expensive - I couldn’t even find one at 2.7” or larger on the “maker kit” sites, only as raw components. > don't forget that you also have to have buttons/switches to go along with the > display. don't assume that people are going to have a spare USB keyboard > around to plug in. > > There is a substantial population who's only computers are tablets, phones, > TVs, and other non-traditional devices, but who need wifi to use them. Keyboard, mouse, xbox/ps4/wii controller - don’t care. They’ll either have at least one of those (basic models are cheap), or we can auto-generate a basic working configuration and display the resulting wifi SSID/password on the screen. The only button needed is a factory-reset. If they don’t have anything with an Ethernet connection, they would have difficulty configuring most existing routers from the factory-reset state anyway. I just made a brief search for WPS on my Android phone - no dice. Apparently there *is* a WPS function, but it’s buried four layers deep in the UI, behind an “advanced” option^W^W “beware of the leopard” sign - and it’s potentially in a different place on each device, making it hard to give directions remotely. But with the wifi SSID and password visible on-screen, we wouldn’t need WPS. That’s something an ordinary router can’t do. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
Hi Jonathan, > On Mar 13, 2016, at 16:18 , Jonathan Morton wrote: > > >> On 13 Mar, 2016, at 02:15, David Lang wrote: >> >> my point is that you can use a browser interface to mock-up what you would >> do on your local display without having to build custom hardware. Yes, it >> would mean you have to work with javascript/etc to build this mockup, but it >> would let you create a bitmap image with buttons/etc that will work the same >> way that your physical device would, but be able to tinker with things that >> would require hardware changes if it was a physical device (different screen >> sizes, button placements, etc) > > And my point is that if I can do that *without* involving a browser, so much > the better. Given my existing experience, I can probably do it *easier* in > something like C and Xlib (yes, really) than in a browser. > > Yes, it would be a pure software mockup, and thus still easy to change. > >> a 6x8 font on a 2.7" screen is unreadable for many people, this is about an >> 11pt font on something that is not at your optimum reading distance. > > The display I linked has basically the same pixel density as a 1980s/1990s > Macintosh display, a 9-pin dot-matrix printer, and a basic Nokia phone - the > standard 72dpi. Anyone with standard visual acuity should be able to read > 8-pixel-high text on it. Your concern would be limited to that segment of > the population who already needs to buy large-print books and newspapers. > > The most important text wouldn’t be 6x8 - I included that stat only to > contrast it with the 16x2 cell text-only display. Since it’s a graphical > display, we can use larger fonts where desired. > > Incidentally, the classic Nokia phones seem to use a proportional font which > is 5x7 on average. Please note that the classic Nokia phone is dead as a doornail as far as popularity is concerned; that might speak against their ease of use compared with touch screen “smart phones”… (take home message might simply be “aim for a touch screen”) > They sold many millions, probably because they designed a UI that even my > mother could be coached into learning (believe me, that’s a feat). Up, down, > select, cancel, and a numeric keypad. The size of the text on the screen > doesn’t seem to have been a factor. The keypad is sort of helpful to put in say IP addresses (or passwords with a T9 like numerical hash for words system). I have used old HP on printer interfaces to configure IP networking, not an experience I would recommend to emulate (not that you are doing tis, but please keep the failures of old in mind when designing your system). > >> OLEDs do color as well. > > The ones that do colour are even more expensive than the mono ones. > Increasing the size of an OLED display also seems to be incredibly expensive > - I couldn’t even find one at 2.7” or larger on the “maker kit” sites, only > as raw components. That reminds me a bit of https://www.securifi.com/almondplus > >> don't forget that you also have to have buttons/switches to go along with >> the display. don't assume that people are going to have a spare USB keyboard >> around to plug in. >> >> There is a substantial population who's only computers are tablets, phones, >> TVs, and other non-traditional devices, but who need wifi to use them. > > Keyboard, mouse, xbox/ps4/wii controller - don’t care. They’ll either have > at least one of those (basic models are cheap), or we can auto-generate a > basic working configuration and display the resulting wifi SSID/password on > the screen. The only button needed is a factory-reset. > > If they don’t have anything with an Ethernet connection, they would have > difficulty configuring most existing routers from the factory-reset state > anyway. > I just made a brief search for WPS on my Android phone - no dice. > Apparently there *is* a WPS function, but it’s buried four layers deep in the > UI, behind an “advanced” option^W^W “beware of the leopard” sign - and it’s > potentially in a different place on each device, making it hard to give > directions remotely. > > But with the wifi SSID and password visible on-screen, we wouldn’t need WPS. > That’s something an ordinary router can’t do. Well, a lot of ISP supplied routers have a sticker on the back giving exactly the information (in addition to the password for the web-gui), your alternative would make it easier to change the password and/or SSID; but while the password could be randomized, I envision user unhappiness with randomized SSIDs… ;) Best Regards Sebastian > > - Jonathan Morton > > ___ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
It's a really big present and future market, and ideas like these are being explored. Multiple wifi-router-with-display projects were launched on kickstarter, some are shipping. I evaluated one, only to find it was all gui, slapped on top of an antiquated kernel. Other enterprise players focused on making hundreds of devices easier to manage, without focusing on the underlying tech much. Currently hot is the idea of using an app to control the device, rather than a web browser. eero is doing this, so are others. but my own thing is this tiny, tiny little bit of an overall next-gen wifi or wireless product - getting the queue theory right, and "out there"as a basic component of everything, no matter what is layered on top. This is *hard*. Work is just beginning. Delivering a polished product with all the desirable features is 99.999% more work than that. Realizing, that in wifi, most of the problems can't be solved at the AP, but in the clients and their drivers, depressing. If it were possible to assemble a funded team to produce an "openwifi" product - or one as open as possible, as seems possible with the mediatek chipset - I'd join it. Same goes for producing open hardware ip for wifi to be, say, co-joined with the risc-v or millcomputing work. But we're talking millions of dollars here even with university help. I helped fund this - http://www.meshsr.com/ - to no nearly no avail, but there is a lot of work taking place on the zynq derived FPGAs that one day might see the light as ASICs. http://www.mathworks.com/hardware-support/zynq-sdr.html?requestedDomain=www.mathworks.com There are niche markets opening, in other spectrum bands (802.11ad), and I still retain hope that UWB could take shape somehow, maybe as an in-house backhaul... It may well be that micro-cells from 5G will be the wave of the future. ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
> On 13 Mar, 2016, at 19:40, moeller0 wrote: > > Please note that the classic Nokia phone is dead as a doornail as far as > popularity is concerned; that might speak against their ease of use compared > with touch screen “smart phones”… (take home message might simply be “aim for > a touch screen”) The first hit when Googling for “nokia feature phone sales figures” threw up a fairly recent article (http://www.ibtimes.com/microsoft-making-more-money-sales-feature-phones-smartphones-2154087) which states that: 1) Microsoft (which bought Nokia’s phone business) made more money from feature phones (the ones with tiny screens and physical keypads) than from smartphones that quarter. Since the ASP of a feature-phone is much lower than a smartphone, you can make the obvious conclusions about how *many* sold in each category. 2) Sales of feature phones actually *increased* over the previous quarter, and not by a trivial factor. Although the article then goes on to predict the complete demise of the feature-phone segment, that conclusion does not seem to be supported by the facts it quotes. It also mentions that feature-phones (with certain specific design features such as large buttons) are preferred by the elderly, even though touchscreen phones have larger screens and thus, theoretically, more space for large fonts. One factor you may not have considered is that feature-phones still sell very well in the third world, mainly because they’re durable, power-efficient and cheap, but their ease of use surely doesn’t hurt there. The *second* hit from that Google search is Wikipedia’s list of best-selling phones. Top of the list are the venerable Nokia 1100 and 1110, which together sold *half a billion* units over their lifetime. The famous 3310 sold “only” 150 million - and I still have mine. It’s on its third battery, which lasts an entire week on standby. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd wrote: > On 12 March 2016 at 11:14, Henning Rogge wrote: >> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman >> wrote: >>> I understand that Broadcom was paid to develop the Pi, a totally free board. >>> >>> And they already make wireless chipsets. >> >> The question is how easy would it be to build a modern 802.11ac >> halfmac chip... the amount of work these chips do (especially with 3*3 >> or 4*4 MIMO) is not trivial. > > It's not that scary - most of the latency sensitive things are: > > * channel change - eg background scans > * calibration related things - but most slow calibration could be done > via firmware commands, like the intel chips do! > * transmit a-mpdu / retransmit > * transmit rate control adaptation > * receiving / block-ack things - which is mostly done in hardware anyway > * likely some power save transition-y things too > > If you're doing STA mode, then you have more things to do - eg bgscans > with active traffic, TDLS, P2P, etc. > If you're doing hostap mode or heck, even mostly-dumb ibss mode - > where there's no requirement for off-channel traffic - the firmware is > mostly just a transmit/receive engine and some power save stuff. > > And honestly - know how many cycles a modern CPU has? If you don't > care about hyper-optimising for power consumption (ie, you're not a > phone), then I bet you could get away with ath9k model hardware. Those > same lower end CPUs can do 200kpps on an ethernet NIC right now. The > reordering and retransmit stuff could be handled in firmware, but > that's about it - and again, only if you wanted to do it on some > anenmic SoC or you cared about power. It is not always "cycles" as context switch latency - which is often mitigated (now) by having general purpose multi-core hardware available, but still hard to get into the us range reliably enough. That said, doing 802.11ac right requires a LOT of on-board DSP processing, and the design of the first chips out the door pre-dated the arrival of modern multi-cores. I certainly think that everything we laid out to improve wifi in make-wifi-fast is now doable on nearly all now-shipping processors and on the ath9k - and work is also proceeding on non-open-source versions of the ideas in iwl and in the next gen ath10k based products. Lots of discussion on the linux-wireless mailing list and patches landing. I do, very much, want to avoid the separate baseband processor that inhabits most cell designs and retain the core smarts for wifi in general purpose processors. Getting locked into a celluar patent and binary blob model would be a bad thing. > > People keep talking about "oh god, these things do so much now" - but > that's because people are thinking about phones or those L2-cache-less > anemic older SOCs that are massively memory bandwidth constrained. > Newer stuff is much less terrible. The ath9k has a long life in it yet, particularly at 2.4ghz, agreed. Yet, I look at the new pi, and see a broadcom chip and driver that could be improved much. I see dozens of other wifi chips that could use more software and design effort, and more coming down the pike. And I gotta admit that 802.11ac, even in it's current state, is now superior to 802.11n in nearly every way, except for the shoddy state of the usually binary-only firmware. Which has got a lot better over the past year. I can see - just as it happened to modems - more soft-mac-is wifi chips arriving like the mt72 - or approaches that load the entire stack on an ethernet-like interface. What I don't see is enough students and engineers with sufficient background in how wifi really works available to handle the billions of devices yet to be shipped. I'd like to attach a knowledge vacuum to your brain, adrian, for example One of the things obscured by the "whole router lockdown" debate here is that the binary blob problem is most acute on the next-gen 802.11ac chips (well, also acute on the video drivers). Anybody using those blobs can certainly not lock down the entire router, and ship a blob for the wifi. Which is historically what has always happened here - the ath9k being the sole exception. Blobs are a PITA in themselves. At one positive note, I think usb-wifi interfaces are going to go the way of the dodo, and be replaced almost entirely by on-board interfaces, for which I hope for a blob-free outcome on at least one design. > > > > -adrian > ___ > bufferbloat-fcc-discuss mailing list > bufferbloat-fcc-disc...@lists.redbarn.org > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
> On Mar 13, 2016, at 18:48 , Dave Taht wrote: > […] > Currently hot is the idea of using an app to control the device, > rather than a web browser. eero is doing this, so are others. […] It is rather sad, that “apps” are the new browser pages… I will take a shitty web interface over an app interface most days. At least with the web interface I am reasonably certain that at least the client interface (aka the browser) will keep getting updates… But I guess I am turning into a relic rapidly… Also I claim that neither app nor web interface will be able to hide all the complexity inherent in setting up a home network unless they restrict the user inappropriately Best Regards Sebastian ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
Hi Jonathan, > On Mar 13, 2016, at 19:17 , Jonathan Morton wrote: > > >> On 13 Mar, 2016, at 19:40, moeller0 wrote: >> >> Please note that the classic Nokia phone is dead as a doornail as far as >> popularity is concerned; that might speak against their ease of use compared >> with touch screen “smart phones”… (take home message might simply be “aim >> for a touch screen”) > > The first hit when Googling for “nokia feature phone sales figures” threw up > a fairly recent article > (http://www.ibtimes.com/microsoft-making-more-money-sales-feature-phones-smartphones-2154087) > which states that: > > 1) Microsoft (which bought Nokia’s phone business) made more money from > feature phones (the ones with tiny screens and physical keypads) than from > smartphones that quarter. Since the ASP of a feature-phone is much lower > than a smartphone, you can make the obvious conclusions about how *many* sold > in each category. > > 2) Sales of feature phones actually *increased* over the previous quarter, > and not by a trivial factor. > > Although the article then goes on to predict the complete demise of the > feature-phone segment, that conclusion does not seem to be supported by the > facts it quotes. It also mentions that feature-phones (with certain specific > design features such as large buttons) are preferred by the elderly, even > though touchscreen phones have larger screens and thus, theoretically, more > space for large fonts. > > One factor you may not have considered is that feature-phones still sell very > well in the third world, mainly because they’re durable, power-efficient and > cheap, but their ease of use surely doesn’t hurt there. > > The *second* hit from that Google search is Wikipedia’s list of best-selling > phones. Top of the list are the venerable Nokia 1100 and 1110, which > together sold *half a billion* units over their lifetime. The famous 3310 > sold “only” 150 million - and I still have mine. It’s on its third battery, > which lasts an entire week on standby. > > - Jonathan Morton > I stand corrected. I am sorry that I distracted from the point I wanted to make by a rather pointless “drive-by” insult to feature phones. I also fondly remember my 3310, but I certainy do not want to go back there, that week of standby be damned ;) Best Regards Sebastian ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
> On 13 Mar, 2016, at 20:25, moeller0 wrote: > > I also fondly remember my 3310, but I certainy do not want to go back there, > that week of standby be damned ;) I don’t actually use my 3310 very much - it’s there for emergencies more than anything else. But I do think it makes a better phone than my Android phablet. The latter is pretty good at the whole “internet terminal” and “utility app” thing, but it’s a pretty lousy phone. Indeed the “make a phone call” functionality is presented as just another app, albeit one that can’t be uninstalled. I can’t even type a text message any faster on it (to the same accuracy) than on my 3310. It works adequately as a phone, rather than well. > while the password could be randomized, I envision user unhappiness with > randomized SSIDs I don’t see why - that’s the one they don’t have to type, because it gets scanned for. A straight random string of characters from the base64 or base85 character sets would be hard to recognise or read out loud, but I was thinking more along the lines of picking randomly from wordlists, so you’d get SSIDs of the form “AdjectiveNoun” which are relatively easy to recognise and remember, yet still likely to be locally unique. Passwords chosen by a similar method (ie. virtual diceware) would also be easier to type, etc. CorrectHorseBatteryStaple... > That reminds me a bit of https://www.securifi.com/almondplus The eye-watering price is certainly notable. It’s unclear how much of that is profit margin, and how much went into the screen. I note also the touchscreen UI, at which I have to squint to work out what each icon is for (despite the bright, high-res colour screen). There’s a lot to be said for the old Amstrad PCW type of UI. Very little window dressing, straight down to business. > The keypad is sort of helpful to put in say IP addresses (or passwords with a > T9 like numerical hash for words system). I have used old HP on printer > interfaces to configure IP networking, not an experience I would recommend to > emulate (not that you are doing tis, but please keep the failures of old in > mind when designing your system). I just looked up a few HP printer manuals to see what you’re talking about. Setting numerical values by incremental button presses does sound tedious - but I already knew that from badly-designed microwave ovens. The cheap ones come with a clockwork dial, which is actually easier to use than the typical “increment 10 mins, 1 min or 10 sec” buttons. I deliberately bought a good one with a digital dial. At university, I often saw people routinely set the microwave timer for 10 minutes, simply because it required fewer button presses than the correct setting. We had a lot of false fire alarms. But I’m not presently considering putting buttons on the device itself. The screen will be a significant expense in itself; adding enough buttons to be a worthwhile input device sounds like another big cost. But there’ll be a USB port somewhere anyway, and most users will have something worthwhile to plug into it. Clearly a keyboard will be the preferred input device. Though there are many national layouts, we can rely on arrow keys, a full Latin alphabet, Arabic numerals, space, backspace and return giving consistent keycodes. Or at least, we can once we correct for QWERTY/QWERTZ/AZERTY/Dvorak quirks - we can prompt the user to press the Z key to distinguish between these. Rapid and accurate navigation and data entry should then be easy. As a subtype of keyboards, though, there are standalone numeric keypads, essentially the part missing from a laptop keyboard. Those may merit special consideration - they don’t have a Z key. There are established ways of navigating menus and entering text using console controllers - since that’s a problem consoles themselves have had to solve. It’s clunky, but somehow they get people to pay $60 per game for the privilege of entering CD key codes this way. It should also be feasible to allow a mouse to be used. Almost all mice these days have a scroll wheel, which we can use to scan through the character set instead of trying to squeeze a virtual keyboard onto the screen. Navigation would be by pointing, left-click to select, right-click to cancel/exit. If this sounds like a complex solution to a problem - maybe it is, at the design level. I think users will find it simple. That matters more. > Well, a lot of ISP supplied routers have a sticker on the back giving exactly > the information (in addition to the password for the web-gui) My Buffalo router has such a sticker. It says the web-UI login is root/(blank). That, right there, is my best argument against Web configuration interfaces - they are impossible to secure in the factory-fresh state. - Jonathan Morton ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.ne
Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
Hi Jonathan, > On Mar 13, 2016, at 21:15 , Jonathan Morton wrote: > > >> On 13 Mar, 2016, at 20:25, moeller0 wrote: >> >> I also fondly remember my 3310, but I certainy do not want to go back there, >> that week of standby be damned ;) > > I don’t actually use my 3310 very much - it’s there for emergencies more than > anything else. But I do think it makes a better phone than my Android > phablet. > > The latter is pretty good at the whole “internet terminal” and “utility app” > thing, but it’s a pretty lousy phone. Indeed the “make a phone call” > functionality is presented as just another app, albeit one that can’t be > uninstalled. I can’t even type a text message any faster on it (to the same > accuracy) than on my 3310. It works adequately as a phone, rather than well. My sentiment as well; only I realized I value a mobile internet terminal (with acceptable phone capability) more than an excellent phone without internet access ;) > >> while the password could be randomized, I envision user unhappiness with >> randomized SSIDs > > I don’t see why - that’s the one they don’t have to type, because it gets > scanned for. > > A straight random string of characters from the base64 or base85 character > sets would be hard to recognise or read out loud, but I was thinking more > along the lines of picking randomly from wordlists, so you’d get SSIDs of the > form “AdjectiveNoun” which are relatively easy to recognise and remember, yet > still likely to be locally unique. > > Passwords chosen by a similar method (ie. virtual diceware) would also be > easier to type, etc. CorrectHorseBatteryStaple… I had considered this, but looking at the SSIDs in my neighborhood, people either stick to the default or pick something clever/funny; and dice ware will not allow those users to fulfill their wittiness. For passwords that might work, have people “roll” a fresh one until they like the result … > >> That reminds me a bit of https://www.securifi.com/almondplus > > The eye-watering price is certainly notable. It’s unclear how much of that > is profit margin, and how much went into the screen. I note also the > touchscreen UI, at which I have to squint to work out what each icon is for > (despite the bright, high-res colour screen). The price is putting this well into the life-style accessory terrain ;) (I wonder whether this thing actually sells, but its main selling point is the display so I thought it relevant to the current discussion). > > There’s a lot to be said for the old Amstrad PCW type of UI. Very little > window dressing, straight down to business. > >> The keypad is sort of helpful to put in say IP addresses (or passwords with >> a T9 like numerical hash for words system). I have used old HP on printer >> interfaces to configure IP networking, not an experience I would recommend >> to emulate (not that you are doing tis, but please keep the failures of old >> in mind when designing your system). > > I just looked up a few HP printer manuals to see what you’re talking about. > Setting numerical values by incremental button presses does sound tedious - > but I already knew that from badly-designed microwave ovens. The cheap ones > come with a clockwork dial, which is actually easier to use than the typical > “increment 10 mins, 1 min or 10 sec” buttons. I deliberately bought a good > one with a digital dial. > > At university, I often saw people routinely set the microwave timer for 10 > minutes, simply because it required fewer button presses than the correct > setting. We had a lot of false fire alarms. > > But I’m not presently considering putting buttons on the device itself. The > screen will be a significant expense in itself; adding enough buttons to be a > worthwhile input device sounds like another big cost. But there’ll be a USB > port somewhere anyway, and most users will have something worthwhile to plug > into it. Honestly, if it is not self sufficient, then an display-only solution seems inferior to even a mediocre web-interface, given that everybody (requiring to set-up a router) probably is browser-proficient already. Having the display in addition is superior for sure. > > Clearly a keyboard will be the preferred input device. Though there are many > national layouts, we can rely on arrow keys, a full Latin alphabet, Arabic > numerals, space, backspace and return giving consistent keycodes. Or at > least, we can once we correct for QWERTY/QWERTZ/AZERTY/Dvorak quirks - we can > prompt the user to press the Z key to distinguish between these. Rapid and > accurate navigation and data entry should then be easy. I believe using a web browser for access solves these issues quite elegantly ;) > > As a subtype of keyboards, though, there are standalone numeric keypads, > essentially the part missing from a laptop keyboard. Those may merit special > consideration -
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sun, 13 Mar 2016, Brandon Butterworth wrote: On Sat, 13 Mar 2016, David lang wrote: I would do us no good to create a fully open chip if the FCC mandates that the firmware must be locked down. Which firmware must be locked down? I was under the impression that is just retail end user devices, is the suggestion that chip manufacturers will not be allowed to sell parts to people who might make a non locked down device? Does that include if they don't supply firmware and the user writes their own/reverse engineers others? Sounds like a road to future regulating all rf hardware sale (stop people selling rp connectors as it's letting them circumvent the antenna limitations they were designed to impose?) Given the interference that caused this is a few incidents a year compared to the millions of units sold and that those cases were either bad users or caused by faulty devices it seems that the lock down would have to be total to prevent future incidents. Quite impractical. the original proposed ruling specifically asked for ways to block loading DD-WRT on devices. If the FCC requires a lockdown like this, then it becomes something they test during the certification process, so unless you buy the chips and build something yourself that is not certified, you can't user it. That would mean that even if we were to build a free component, we would never see it in any devices that aren't locked down. Would I like someone to do this, Sure. I'll contribute towards a kickstarter, even if it's $100 for a mini-pci card that is the equivalent of what we can get today for $30, but it would take tens of thousands of people doing that to fund the project, and I have serious doubts if you can get that much funding for something with such a long lead time. It think it would be cheaper and quicker to reverse engineer drivers for others hardware. Even if the cost could be covered to build it'd lag commercial products by years making it a difficult sell, and likely subjected to IPR claims from current manufacturers the issue isn't the drivers, it's in the firmware running on the radio chip. That does a lot of stuff (implements the entire 801.11 protocol) If someone does the research and puts together a FPGA version That could be an interesting project. It may not help but we have an FPGA MIMO implementation we may be able to release to such a project (it may be unsuitable though, we've been making radio cameras https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+mimo https://www.google.co.uk/?gws_rd=ssl#q=bbc+r%26d+halfrf ) and is looking for funding to convert it to a ASIC, I think you could get funding. But that's not the question in front of us now. Yes, and if the lock down expands to chips too would have the same problem As I understand it, every 802.11ac chipset is using closed-source firmware. The proposal was to solve this by createing a new chipset with open firmware. That isn't going to be useful if it's only a FPGA implementation that is priced out of range for commercial products, so whatever is built to be a replacement chipset would have to be reduced to ASIC or it won't be cheap enough to be used. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
On Sun, 13 Mar 2016, Wayne Workman wrote: I actually like the idea of having a small display on a consumer router. Obviously this would not be cost effective for enterprise grade, though, when a network administrator is overseeing 2,000 access points remotely, he does not care about a display on the device, he cares about functionality and cost. But back to having a small screen. Newer high-end business HP network printers have had a small display for a really long time. I really like it, and it allows me to very quickly have the printer print out (on paper) it's configuration. I can also quickly get to some common areas that way. But, all these printers with small displays... they have a full-on Web interface as well. So I'd ask for what you do to be able to tie into a web interface at a later time. But maybe we could go with cheaper hardware if we didn't need to run a full Web server? no, a webserver is really cheap to run. I expect that you would not be able to tell the difference in CPU load between running a webserver and driving a built-in display. David Lang On Mar 13, 2016 10:19 AM, "Jonathan Morton" wrote: On 13 Mar, 2016, at 02:15, David Lang wrote: my point is that you can use a browser interface to mock-up what you would do on your local display without having to build custom hardware. Yes, it would mean you have to work with javascript/etc to build this mockup, but it would let you create a bitmap image with buttons/etc that will work the same way that your physical device would, but be able to tinker with things that would require hardware changes if it was a physical device (different screen sizes, button placements, etc) And my point is that if I can do that *without* involving a browser, so much the better. Given my existing experience, I can probably do it *easier* in something like C and Xlib (yes, really) than in a browser. Yes, it would be a pure software mockup, and thus still easy to change. a 6x8 font on a 2.7" screen is unreadable for many people, this is about an 11pt font on something that is not at your optimum reading distance. The display I linked has basically the same pixel density as a 1980s/1990s Macintosh display, a 9-pin dot-matrix printer, and a basic Nokia phone - the standard 72dpi. Anyone with standard visual acuity should be able to read 8-pixel-high text on it. Your concern would be limited to that segment of the population who already needs to buy large-print books and newspapers. The most important text wouldn’t be 6x8 - I included that stat only to contrast it with the 16x2 cell text-only display. Since it’s a graphical display, we can use larger fonts where desired. Incidentally, the classic Nokia phones seem to use a proportional font which is 5x7 on average. They sold many millions, probably because they designed a UI that even my mother could be coached into learning (believe me, that’s a feat). Up, down, select, cancel, and a numeric keypad. The size of the text on the screen doesn’t seem to have been a factor. OLEDs do color as well. The ones that do colour are even more expensive than the mono ones. Increasing the size of an OLED display also seems to be incredibly expensive - I couldn’t even find one at 2.7” or larger on the “maker kit” sites, only as raw components. don't forget that you also have to have buttons/switches to go along with the display. don't assume that people are going to have a spare USB keyboard around to plug in. There is a substantial population who's only computers are tablets, phones, TVs, and other non-traditional devices, but who need wifi to use them. Keyboard, mouse, xbox/ps4/wii controller - don’t care. They’ll either have at least one of those (basic models are cheap), or we can auto-generate a basic working configuration and display the resulting wifi SSID/password on the screen. The only button needed is a factory-reset. If they don’t have anything with an Ethernet connection, they would have difficulty configuring most existing routers from the factory-reset state anyway. I just made a brief search for WPS on my Android phone - no dice. Apparently there *is* a WPS function, but it’s buried four layers deep in the UI, behind an “advanced” option^W^W “beware of the leopard” sign - and it’s potentially in a different place on each device, making it hard to give directions remotely. But with the wifi SSID and password visible on-screen, we wouldn’t need WPS. That’s something an ordinary router can’t do. - Jonathan Morton ___ bufferbloat-fcc-discuss mailing list bufferbloat-fcc-disc...@lists.redbarn.org http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
On Sun, 13 Mar 2016, Wayne Workman wrote: Would a "Kit" router be a potential solution? Buy the board with all it's components but the chipset already in place, and buy the chipset separately? Then, the device being sold is non-functional, and therefore guaranteed to pass even the strictest FCC regulations regarding Radio Emissions. :-) Buy your own chip and solder it on. most programmers can't operate a soldering iron for a normal chip, let alone a surface mount chip. are you trying to provide something for a few hundred hobbiests? or are you trying to produce something that will help the general public? And if the FCC requires locked firmware, you won't be able to make a mini-pci board, just the raw chips. Will you be able to sell enough to get the cost down to a reasonable level? David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sun, 13 Mar 2016, Adrian Chadd wrote: You do that in hardware. Do the Mac, phy and RF in hardware. This is what the qca hardware does. unfortunantly, that's not what the existing chipsets do. So unless you can create a new chipset, you can't just change what's done in hardware. David Lang a On Mar 13, 2016 5:25 PM, "David Lang" wrote: On Sat, 12 Mar 2016, Adrian Chadd wrote: On 12 March 2016 at 11:14, Henning Rogge wrote: On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman wrote: I understand that Broadcom was paid to develop the Pi, a totally free board. And they already make wireless chipsets. The question is how easy would it be to build a modern 802.11ac halfmac chip... the amount of work these chips do (especially with 3*3 or 4*4 MIMO) is not trivial. It's not that scary - most of the latency sensitive things are: * channel change - eg background scans * calibration related things - but most slow calibration could be done via firmware commands, like the intel chips do! * transmit a-mpdu / retransmit * transmit rate control adaptation * receiving / block-ack things - which is mostly done in hardware anyway * likely some power save transition-y things too you are ignoring MU-MIMO, the ability to transmit different signals from each antenna so that the interference patterns from the different signals result in different readable data depending on where the receiver is in relation to the access point is not a trivial thing. But it's one of the most valuable features in the spec. David Lang ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
