[Cerowrt-devel] arstechnica confirms tp-link router lockdown

[Cerowrt-devel] arstechnica confirms tp-link router lockdown

[Dave Taht]

http://arstechnica.com/information-technology/2016/03/tp-link-blocks-open-source-router-firmware-to-comply-with-new-fcc-rule/

I've tweeted, facebooked, and g+'d. I've also seen it just hit the fcc
list, and perhaps it will cross over into more media (with a little
help from y'all?) I also matched the donations to the savewifi site
over the past month (620 or so) with a matched donation to:
https://www.gofundme.com/save_wifi_round_2/

Also of ironic interest today was:

http://mjg59.dreamwidth.org/40505.html

--
Dave Täht
Do you really want software in your house you cannot control?
https://www.gofundme.com/save_wifi_round_2/

Re: [Cerowrt-devel] arstechnica confirms tp-link router lockdown

[Luis E. Garcia]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Time to start building our own.

On Fri, Mar 11, 2016 at 10:17 AM, Dave Taht <dave.taht@gmail.com> wrote:

>
> http://arstechnica.com/information-technology/2016/03/tp-link-blocks-open-source-router-firmware-to-comply-with-new-fcc-rule/
>
> I've tweeted, facebooked, and g+'d. I've also seen it just hit the fcc
> list, and perhaps it will cross over into more media (with a little
> help from y'all?) I also matched the donations to the savewifi site
> over the past month (620 or so) with a matched donation to:
> https://www.gofundme.com/save_wifi_round_2/
>
> Also of ironic interest today was:
>
> http://mjg59.dreamwidth.org/40505.html
>
> --
> Dave Täht
> Do you really want software in your house you cannot control?
> https://www.gofundme.com/save_wifi_round_2/
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 1914 bytes --]

Re: [Cerowrt-devel] arstechnica confirms tp-link router lockdown

[Jonathan Morton]

> On 11 Mar, 2016, at 20:22, Luis E. Garcia <luis@bitamins.net> 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.

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.

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.

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

Re: [Cerowrt-devel] arstechnica confirms tp-link router lockdown

[Alan Jenkins]

On 11/03/2016, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 11 Mar, 2016, at 20:22, Luis E. Garcia <luis@bitamins.net> 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.

Actually, devices show up in Windows "network neighborhood".  Routers
show up because of uPnP (IGD specifically), which of course everyone
implements out of the box.  Clicking the router opens a web interface.
I don't know if that's hard-coded as http://ipv4-address:80 or what,
but even that's really hard to criticize.

Equally I don't know that people know to click "Network" in their file
browser, or that it's reliable enough that that's what you put in the
manual.  But it's the sort of thing a journalist who's reviewed a few
different routers is likely to be aware of.

I like the idea behind WPS, holey as that is.  You've got a point
about people having to use the manual anyway, but it's got to be a big
step up from keying passwords into your phone etc.

I know, in practice and implementation it gets cringeworthy.

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.

The BT Hub interface is locked down and very simplified; I expect if
you disconnect it you get a nice  prominent error with the obvious
advice.

Equally you can get quite friendly LEDs.  The classic Netgear DG834
gets a nice red light if it can't connect.  Maybe another shade during
connection, and otherwise the only lights are green.  If it's red,
check the cables, then try logging in to see what's gone wrong.  If
logging on doesn't show an obviously dead router, call ISP support to
see if they're having problems in your area.

Just because they screwed up the WNDR3800 with too many different
coloured lights, it doesn't invalidate the principle.

WiFi makes for annoyingly more failure modes.  USB ethernet adaptors
are cheap and standard - certain types of router actually have them
built in for you.

Grandpa and his iPad are more challenging.  But he probably needs to
stick to the ISP-provided router and rely on their helpline.  If you
want to choose your router, needing ethernet or usb A isn't going to
be any barrier to you.

> 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.
>
> 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.

IOW I'm not convinced by that particular suggestion :).

At the point when I'm trying to troubleshoot it, I want dead trees and
my own computer.  No squinting etc.

> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4565 bytes --]

On Fri, 11 Mar 2016, Alan Jenkins wrote:

> On 11/03/2016, Jonathan Morton <chromatix99@gmail.com> wrote:
>>
>>> On 11 Mar, 2016, at 20:22, Luis E. Garcia <luis@bitamins.net> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Jonathan Morton]

> On 11 Mar, 2016, at 22:40, David Lang <david@lang.hm> 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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Henning Rogge]

On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
<wayne.workman2012@gmail.com> 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.

Henning Rogge

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Dave Taht]

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
<wayne.workman2012@gmail.com> 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" <adrian@freebsd.org> wrote:
>>
>> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> > On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> > <wayne.workman2012@gmail.com> 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-discuss@lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5359 bytes --]

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 was a physical device (different screen sizes, button 
placements, etc)

Then if you get an interface that you think is usable, others can test it as 
well, again without having to build custom hardware.

Once you get a working design, then you can talk about custom hardware.

David Lang

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

On Sat, 12 Mar 2016, Adrian Chadd wrote:

> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> <wayne.workman2012@gmail.com> 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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Jonathan Morton]

> On 13 Mar, 2016, at 02:15, David Lang <david@lang.hm> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[moeller0]

Hi Jonathan,


> On Mar 13, 2016, at 16:18 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 13 Mar, 2016, at 02:15, David Lang <david@lang.hm> 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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Dave Taht]

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.

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Jonathan Morton]

> On 13 Mar, 2016, at 19:40, moeller0 <moeller0@gmx.de> 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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[Dave Taht]

On Sat, Mar 12, 2016 at 12:18 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>> <wayne.workman2012@gmail.com> 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-discuss@lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[moeller0]

> On Mar 13, 2016, at 18:48 , Dave Taht <dave.taht@gmail.com> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[moeller0]

Hi Jonathan, 
> On Mar 13, 2016, at 19:17 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 13 Mar, 2016, at 19:40, moeller0 <moeller0@gmx.de> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[Jonathan Morton]

> On 13 Mar, 2016, at 20:25, moeller0 <moeller0@gmx.de> 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

Re: [Cerowrt-devel] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[moeller0]

Hi Jonathan,

> On Mar 13, 2016, at 21:15 , Jonathan Morton <chromatix99@gmail.com> wrote:
> 
> 
>> On 13 Mar, 2016, at 20:25, moeller0 <moeller0@gmx.de> 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 - 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 comes as an additional/emergency method to access the device this all sounds great, but as the main method that does not seem to be superior to a reasonably well made web-interface (or as much as I dislike those an “app” interface). But I am fully aware that this is a) a matter of taste and b) my taste is quite peculiar (meaning I have no clue what the “masses” will like).

> 
> 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.

	I can only speak for my ISP, but each device has a unique(?) password/passcode (which might be trivially deduced from serial and/or mac numbers). So if DTAG can pull this through so could OEMs/ODMs (that after all build the devices the ISPs distribute in the first place).

Best Regards
        Sebastian

> 
> - Jonathan Morton
> 

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5052 bytes --]

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" <chromatix99@gmail.com> wrote:
>
>>
>>> On 13 Mar, 2016, at 02:15, David Lang <david@lang.hm> 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-discuss@lists.redbarn.org
>> http://lists.redbarn.org/mailman/listinfo/bufferbloat-fcc-discuss
>>
>

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] [Make-wifi-fast] arstechnica confirms tp-link router lockdown

[David Lang]

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

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

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" <david@lang.hm> wrote:
>
>> On Sat, 12 Mar 2016, Adrian Chadd wrote:
>>
>> On 12 March 2016 at 11:14, Henning Rogge <hrogge@gmail.com> wrote:
>>>
>>>> On Sat, Mar 12, 2016 at 3:32 PM, Wayne Workman
>>>> <wayne.workman2012@gmail.com> 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
>>
>

Re: [Cerowrt-devel] [bufferbloat-fcc-discuss] arstechnica confirms tp-link router lockdown

[David Lang]

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