Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
> On 11 Mar, 2016, at 22:40, David Lang wrote: > Actually, devices show up in Windows "network neighborhood”. Ah, you see, I tend to keep Windows off my network until the network itself is set up. Also, there’s a Linux machine sitting between the LAN and the modem, which effectively blocks UPnP. That’s probably why I haven’t noticed such subtleties - that, and they aren’t listed in the router manuals I’ve read to date. Maybe I just have old routers. > But the biggest barrier is probably that the web interface is > cluttered with features you don't need, so there's a setup wizard you > go through once, and you don't touch that even if you're curious > because you're at risk of resetting it. That’s a good observation, and suggests a design principle to follow in future. > Just because they screwed up the WNDR3800 with too many different > coloured lights, it doesn't invalidate the principle. It’s not just the WNDR, and not just Netgear. Every router I’ve seen has too many lights which provide too little information - and even I have to squint and read the manual to figure out what it’s telling me. Except Apple. Then you have *one* light which provides too little information - but at least I don’t have to read the manual to figure it out. :-) > You have a much larger display, which gives you room for help text and > images, not just a handful of characters. You might assume that I’m thinking of a 16x2 character display. I’m not - that’s too small to be user-friendly. Rather, something like this, which gives 128x64 pixels (equivalent to 21x8 characters with a 6x8 font) and the freedom to draw icons and choose fonts: https://www.adafruit.com/products/250 There are also small OLED displays which give a sharper, higher-contrast readout, but these are more expensive, lack the capacity of colour-coding anything, and appear to be so small that some people might have difficulty reading them despite the sharpness and high contrast. The original Macintosh put a whole desktop environment on a tiny (by modern standards) 512x384 mono display. We don’t even need *that* level of sophistication. I’m confident 128x64 mono will be enough if carefully designed for - it is substantially more than a classic Nokia phone provided. > A display is nicer than just LEDs, but it's also a lot more expensive. Yes, it looks like a decent display+controller combination is more expensive than a mini-PCIe ath9k card (even discounting the markup associated with Adafruit providing a maker-friendly kit rather than raw devices). It will therefore be a significant contributor to the BOM cost. This is justifiable if it also contributes to the USP. On the upside, with a status display we can reduce the number of LEDs and associated optical channels, perhaps all the way down to a single power light. > 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) An RGB LED backlight can inherently be dimmed - and this could occur automatically when out of setup mode (keyboard disconnected) and the overall status is OK. Also, since it illuminates a relatively large area, the colour can be discerned without high brightness in the first place. > 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. Yes, I probably should. > 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. Since the entire point of my proposal is to get away from the “web interface” concept altogether, and I have an allergic reaction to “web technology” such as JavaScript (spit), that’s *not* what I’m going to do. Instead, I’ll prototype something based around an emulation of the display linked above. But I will take a careful look at Luci to help generate a requirements checklist. - Jonathan Morton ___ 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 Fri, Mar 11, 2016 at 9:09 PM, Dave Taht wrote: > Changing the topic. I'd like the arstechnica discussion to remain > political > > On Fri, Mar 11, 2016 at 11:31 AM, Paul Vixie wrote: > > 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. > > I totally approve of people getting together and building things they > think the market needs, or merely what they think they need. > Ironically, in 1999, the designs I was shopping around for a "home > wireless AP" were designed to plug into where the thermostat was in a > house, had a touchscreen (and ran x-windows remotely), and sank > without a trace past a VC's glazed eyes over and over again. Then the > wrt happened. in 2002... and 15 years later, Nest happened... sigh. > > The segment of "makers", the essential R&D, ultimately feeds into more > polished products, and people should try making those too. There are > billions of devices left to be built in the next decade, and plenty of > room for innovation, and the best, not necessarily the cheapest, like > tp-link - will win - and it's my hope that certain values we have here > will propagate into the successful products. We're not particularly > good at final products, however. > > ... I had a nice visit over at eero yesterday. Their CTO greeted me > with a flash stick outstretched, containing their (debian-based) code. > ;) I was very impressed that they went from kickstarter to a US-wide > launch of their product(s), with enough people, and with a business > model that makes sense (selling three 2-radio diversity meshed routers > at a time to get better coverage (and improve margins)), that they > seem to understand the need for remote updates deeply, AND the need to > make things simple for ordinary users. They also seem to grok things > we are really bad at, like getting finished products on shelves. > > ... 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? > > > I am rooting for them, also, hard! They've made all the right choices > technically and it's (aside from the wifi, currently) the best chipset > possible from an open source perspective. They - unlike nearly all the > home router makers and CPE vendors, have a perspective driven by the > problems they've seen by being a registrar. They have money in the > bank, and low costs, and an idealism about open design that seems > rooted in the maker movement. I'd love to see this market > arduinotized. > > It would be my hope, that with another year's worth of software > development that their design would be suitable for more mass market > CPE, particularly to ISPs in the fiber space. (And that they will be > essentially first to have better wifi as I plan to get stuff working > on that board as soon as I get one in my hot little hands). > > A huge percentage of the former "home router" market is going away as > more and more ISPs bundle the router/wifi and other options into a > single device. That concerns me a lot, and the only thing I can think > of worth doing there is to join this org: http://rdkcentral.com/ and > encourage others to also do so. > > Still, there has to be a lower cost option (for which I'm mostly > chasing mediatek, and sad to have had to have dropped both netgear and > tp-link from further consideration). > > - but who knows - with serious volumes, on a standardized platform > that gets 100ks of deployments by ISPs, manufactured for the long > term, the omnia's costs could drop significantly enough to be > competitive with cheap crap, or, as in the raspberry pi market, a > whole new segment using more standardized firmware will emerge. > > I'd really like to see more devices interoperate in the IoT, as well, > things like making mdns scale better, ipv6 work with naming more > right, etc - perhaps this new wave of folk entering the market - and > others exiting - might actually be able to pull more of the pieces > together. > > > > > -- > > P Vixie > > ___ > > bufferbloat-fcc-discuss mailing list > > bufferbloat-fcc-disc...@lists.redbarn.org > > http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss > ___ > Cerowr
Re: [Cerowrt-devel] [Make-wifi-fast] Will full-duplex be possible on 802.11 wired air?
Last week or so I had a short peek on the lists and read something alike 'half-duplex makes wifi feel slow [in addition to the point in discussion and when compared to wired]'. Now couldn't find the message to reply to the sited one but going on with this one. Half-duplex brought me to a news item national IT press was buzzing about few months ago: Taneli Riihonen's doctoral dissertation "Design and Analysis of Duplexing Modes and Forwarding Protocols for OFDM(A) Relay Links" [1]. 1 http://taneli.riihonen.fi/ "Taneli Riihonen - List of Publications" The fuss news media made out of the research was, that the methods Riihonen found will solely speed up 5G cellular networks. Amusingly I saw a picture a news outlet run out, where Taneli Riihonen was standing and in the background a slide showed text "OFDM". I thought what the heck, this isn't just about 5G, who cares about 5G. Then forgot the news and now got flashback. This might be old news/tidbits for the list, but one can't never be sure, so passing on as in the back of my head are Dave Täht's words that a lot of new research and reading old was made for accomplishment in current state of bufferbloat in wired connections. Getting to the on-the-air-timings spoken about below, the methods Taneli Riihonen found in his dissertation used statistical methods for time slotting the "shout out" and "listen to" for duplexing on the air. Intuitively this brings me to expect that the dissertation might give ideas how to measure timings for tx and rx, and, in the best case readily usable, tools how they have proved their theory in the theses. Sorry I haven't even glimpsed the 300 pages thesis. I'm only basing on slides linked to in the same paragraph as the thesis on the above web-page. Unfortunately the slides are in finnish. -Erkki * Aaron Wood [2016-02-09 06:17:57 +0800]: > I've often wanted the same thing: What's the time-length of given packets > (using various transmission rates), and the inter-packet delays, etc. What > _is_ 100% channel utilization, in terms of packets per second of a given > size/rate? > > From a pcap file full of radio-tap-level packets, can the channel usage be > computed? (none of the tools I looked at a few years ago could give me a > channel usage indication from an analysis of actual packets (with rates and > timestamps)). > > -Aaron > > On Tue, Feb 9, 2016 at 4:02 AM, Dave Täht wrote: > > > Much more readable than the spec! > > > > http://chimera.labs.oreilly.com/books/123401739/ch03.html > > > > I still keep hoping for a comprehensive list (or a tool) for timings for > > every possible operation across all the 802.11 standards. Trying to > > figure out how long things take "on the wire" makes my brain spin. > > > > ___ > > Cerowrt-devel mailing list > > Cerowrt-devel@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > > ___ > Make-wifi-fast mailing list > make-wifi-f...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] [Make-wifi-fast] Will full-duplex be possible on 802.11 wired air?
http://web.stanford.edu/~skatti/pubs/sigcomm13-fullduplex.pdf http://phys.org/news/2013-10-kumu-networks-wireless-full-duplex.html Someone, georgia tech I thought, had actually gone and built a chip to do it. Can't find the link. I have no doubt that we can construct ever more efficient devices, what I have grave doubts about is given the billions of existing devices pee-ing on the spectrum that there will be no way to actually make an impact. For christmas, I gave an unhappy chromecast user the wired dongle. Stuffing stockings full of that sort of stuff, repacing wifi for wired wherever possible, seems like the sanest option. I've been thinking of begging the landlords around me to let me wire up their buildings and tenants for ethernet, from 6pm onwards wifi is getting towards unusable. ... In terms of complexity in serving multiple stations - as opposed to full duplex... The number of DSPs in the 802.11ac mac is well over 400, and MU-mimo, as defined in the standard - really difficult to implement and use effectively. The first MU-mimo capable chips (wave 2) are shipping now, but Not for the last time, I wish we'd got UWB off the ground. Only needed 236 notches cut out of the spectrum a decade ago to make the existing spectrum holders happy. Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Sat, Mar 12, 2016 at 11:20 AM, Erkki Lintunen wrote: > Last week or so I had a short peek on the lists and read something alike > 'half-duplex makes wifi feel slow [in addition to the point in > discussion and when compared to wired]'. Now couldn't find the message > to reply to the sited one but going on with this one. > > Half-duplex brought me to a news item national IT press was buzzing > about few months ago: Taneli Riihonen's doctoral dissertation "Design > and Analysis of Duplexing Modes and Forwarding Protocols for OFDM(A) > Relay Links" [1]. > > 1 http://taneli.riihonen.fi/ "Taneli Riihonen - List of Publications" > > The fuss news media made out of the research was, that the methods > Riihonen found will solely speed up 5G cellular networks. Amusingly I > saw a picture a news outlet run out, where Taneli Riihonen was standing > and in the background a slide showed text "OFDM". I thought what the > heck, this isn't just about 5G, who cares about 5G. Then forgot the news > and now got flashback. > > This might be old news/tidbits for the list, but one can't never be > sure, so passing on as in the back of my head are Dave Täht's words that > a lot of new research and reading old was made for accomplishment in > current state of bufferbloat in wired connections. > > > Getting to the on-the-air-timings spoken about below, the methods Taneli > Riihonen found in his dissertation used statistical methods for time > slotting the "shout out" and "listen to" for duplexing on the air. > Intuitively this brings me to expect that the dissertation might give > ideas how to measure timings for tx and rx, and, in the best case > readily usable, tools how they have proved their theory in the theses. > > Sorry I haven't even glimpsed the 300 pages thesis. I'm only basing on > slides linked to in the same paragraph as the thesis on the above > web-page. Unfortunately the slides are in finnish. > > -Erkki > > > * Aaron Wood [2016-02-09 06:17:57 +0800]: > >> I've often wanted the same thing: What's the time-length of given packets >> (using various transmission rates), and the inter-packet delays, etc. What >> _is_ 100% channel utilization, in terms of packets per second of a given >> size/rate? >> >> From a pcap file full of radio-tap-level packets, can the channel usage be >> computed? (none of the tools I looked at a few years ago could give me a >> channel usage indication from an analysis of actual packets (with rates and >> timestamps)). >> >> -Aaron >> >> On Tue, Feb 9, 2016 at 4:02 AM, Dave Täht wrote: >> >> > Much more readable than the spec! >> > >> > http://chimera.labs.oreilly.com/books/123401739/ch03.html >> > >> > I still keep hoping for a comprehensive list (or a tool) for timings for >> > every possible operation across all the 802.11 standards. Trying to >> > figure out how long things take "on the wire" makes my brain spin. >> > >> > ___ >> > Cerowrt-devel mailing list >> > Cerowrt-devel@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > > >> ___ >> Make-wifi-fast mailing list >> make-wifi-f...@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > ___ > 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] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
You can acquire the 802.11ac specs easiest merely by attending an IEEE 802.11 wg meeting once, and joining to get the ongoing work, and many specs are now increasingly available via: http://www.ieee802.org/11/ The meeting schedule is here: http://www.ieee802.org/11/Meetings/Meeting_Plan.html What is generally coming down the pike (802.11ax, ad, ak, etc) is often quite fascinating, but I have to admit, I am burnt out on going to SDO (standards organization) meetings personally, and yet I long to have a member or members of this group attending IEEE 802.11 regularly. (is anyone here doing so?) I like to think that my talk there in sept 2014 is proving influential (a public version, I gave last august, here: https://www.youtube.com/watch?v=Rb-UnHDw02o ) , but hardware design cycles are long, meetings sometimes mind-numbingly tedious (like all meetings, most of the work takes place in the hallways), sometimes horrifying (lots of people trying to reinvent layer3 at layer 2), and breakthrough technologies are only slowly adopted, particularly when there are major patent holders in the room. I've been meaning to go to next week's meeting, but couldn't raise the funds or allocate the time to go. I still felt going to china would have been worth while. If anyone here wants to hop on a plane?? Dave Täht Let's go make home routers and wifi faster! With better software! https://www.gofundme.com/savewifi On Sat, Mar 12, 2016 at 1:42 PM, Wayne Workman wrote: > Earlier today I was reading over the IC wiki articles our there. I can't > say I understand a lot of it but they all start with a common thing. > Specifications. And I won't pretend to be an expert in defining those > either. But I'd say the 802.11ac specs would likely be what we are after - > and 100% GPLv3 non-negotiable. > > On Mar 12, 2016 2: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. >> >> 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. >> >> >> >> -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] [Make-wifi-fast] arstechnica confirms tp-link router lockdown
On Sat, 12 Mar 2016, Jonathan Morton wrote: quick note, your quotes mixed things I said with things Alan said But the biggest barrier is probably that the web interface is cluttered with features you don't need, so there's a setup wizard you go through once, and you don't touch that even if you're curious because you're at risk of resetting it. That’s a good observation, and suggests a design principle to follow in future. I think this is a significant factor. Just because they screwed up the WNDR3800 with too many different coloured lights, it doesn't invalidate the principle. It’s not just the WNDR, and not just Netgear. Every router I’ve seen has too many lights which provide too little information - and even I have to squint and read the manual to figure out what it’s telling me. Except Apple. Then you have *one* light which provides too little information - but at least I don’t have to read the manual to figure it out. :-) some of the lights are fairly obvious, others less so. You have a much larger display, which gives you room for help text and images, not just a handful of characters. You might assume that I’m thinking of a 16x2 character display. I’m not - that’s too small to be user-friendly. Rather, something like this, which gives 128x64 pixels (equivalent to 21x8 characters with a 6x8 font) and the freedom to draw icons and choose fonts: https://www.adafruit.com/products/250 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. There are also small OLED displays which give a sharper, higher-contrast readout, but these are more expensive, lack the capacity of colour-coding anything, and appear to be so small that some people might have difficulty reading them despite the sharpness and high contrast. OLEDs do color as well. The original Macintosh put a whole desktop environment on a tiny (by modern standards) 512x384 mono display. We don’t even need *that* level of sophistication. I’m confident 128x64 mono will be enough if carefully designed for - it is substantially more than a classic Nokia phone provided. don't ignore the DPI, it's not just the number of pixels, it's the size of the resulting characters. A display is nicer than just LEDs, but it's also a lot more expensive. Yes, it looks like a decent display+controller combination is more expensive than a mini-PCIe ath9k card (even discounting the markup associated with Adafruit providing a maker-friendly kit rather than raw devices). It will therefore be a significant contributor to the BOM cost. This is justifiable if it also contributes to the USP. On the upside, with a status display we can reduce the number of LEDs and associated optical channels, perhaps all the way down to a single power light. 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. If I'm going to drag out a full size keyboard, I sure don't want to be trying to squint at a 2.7" screen. 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) An RGB LED backlight can inherently be dimmed - and this could occur automatically when out of setup mode (keyboard disconnected) and the overall status is OK. Also, since it illuminates a relatively large area, the colour can be discerned without high brightness in the first place. 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. Yes, I probably should. 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. Since the entire point of my proposal is to get away from the “web interface” concept altogether, and I have an allergic reaction to “web technology” such as JavaScript (spit), that’s *not* what I’m going to do. Instead, I’ll prototype something based around an emulation of the display linked above. But I will take a careful look at Luci to help generate a requirements checklist. 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 wa
Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown
On Sat, 12 Mar 2016, Wayne Workman wrote: I understand that Broadcom was paid to develop the Pi, a totally free board. No, Broadcom created a video processor with an embedded ARM cpu. An engineer who works at Broadcom got permission to create a board based on this chip outside of Broadcom on his own time. This board was the original Pi. Broadcom does not develop the Pi or special chips for the Pi. The Pi designers watch what Broadcom makes available and makes use of those chips in their designs. 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 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
