[Arm-netbook] CHIP - The World's First Nine Dollar Computer by Next Thing Co. — Kickstarter

Paul Sokolovsky pmiscml at gmail.com
Tue May 12 23:07:46 BST 2015


Hello,

I managed to receive whole 2 private mails asking for details, so I'm
replying to the list, hoping it would be good intermedia between EOMA
project news. As a disclaimer, I don't know deep details of 802.11
standard, so someone with more knowledge may find bunch of things to
correct. Stylistic otherwise is so it was fun for me to write and fun
for you to read. Caveat emptor.


On Tue, 12 May 2015 16:15:30 -0400
Derek LaHousse <dlahouss at mtu.edu> wrote:

> Hey, I don't know any better, but why would a vendor want to block AP
> mode?  Sure, the end user on a windows machine isn't gonna use it, but
> isn't that more effort to block it?

You may laugh, but Windows supports that for ages. My random google-up
shows this for Windows 7,
http://www.firewall.cx/microsoft-knowledgebase/windows-xp-7-8/968-windows-7-access-point.html ,
but I won't be surprised if some WinXP update allowed that either.

Of course, Microsoft did that years after hostapd
https://w1.fi/hostapd/ was available for Linux. Is Microsoft the only
commercial vendor brave enough to offer such feature? Certainly no,
from a certain version of Android "wifi hotspot" is a standard feature.

The technical story which made this possible is:

Once about a time there was cute WiFi industry with its WEP security
standard. Turned out, that WEP was a complete sieve, and not a
security. Well, cute WiFi industry was just happy to sell you WEP2, but
turned out, the impact was too big. CIOs didn't want to buy that WiFi
thing which could leave them exposed after any vulnerability. So,
pundits at IEEE (which are of course guys from cute WiFi industry) sit
and thought how to not be laughed at again.

What they figured is that they split authentication and authorization
out of core protocol (unlike it was with WEP). So enterprises could
have better security than a password written on a wall, and most
importantly, so they can deliver a promise that if something is
cracked, there should be a firmware upgrade, instead of requiring
thousands of APs off the walls and replacing with other ones.

History is silent regarding the fact whether it was IEEE or some
particular vendor was smart enough to figure out that the easiest way to
implement those requirements is to make a chip pass complete raw 802.11
packets to outside, and get such from outside - then chip can stay
simple (cheap, competetive), and complex and ever-changing crypto can
be done in that "outside", like a main CPU user already has.

That's the idea behind wpa_supplicant https://w1.fi/wpa_supplicant/ .
And surprisingly, ability to pass raw packets has many other interesting
uses, like implementing AP mode. And that's the idea behind
https://w1.fi/hostapd/


Now, could that not work? Sure, vendor could (possibly) allow only
subset of raw packets, or maybe go way of 90ies and WEP and implement
it all on chip. Why? Horizontal segmentation. Selling the same chip for
$2 without that feature, and for $10 otherwise.

Problem: nowadays that's pretty insane. Suppose a user buys an
adapter with such chip and tries to enable standard Windows feature
of virtual AP. And if it doesn't, it cries in twitters and facebooks
"MicroSoft suxxxx!!111". Microsoft doesn't like vendors who do such
things to them, and look at them like sh%t.

Or someone builds a phone with such chip and comes to Google for
Android certification. And they respond: Are you bullocks? A phone can
generate only so much 3G/4G traffic. But if we let a notebook connect
to it, a lot of traffic will be wasted. Without AP mode, your device
simply cannot generate enough revenue for our mobile industry sponsors,
so don't waste our time with it.


And that's the morale of it - at one point, having a closed system is
less beneficial than open, for everyone in the industry - from a user
to various types of vendors and integrators. That's what happened to AP
mode for a WiFi chip - it's stupid to not support it now. That's what we
(subscribers of this list) look for in regard to "mobile"
video/graphics drivers, and other drivers of SoC systems. And what Luke
tries to drive, too bad he doesn't have same kind of leverage as Google
and Microsoft.


> 
> Taken off list because it's not really on-topic, feel free to bring
> back.
> 
> On Tue, May 12, 2015 at 3:31 PM, Paul Sokolovsky <pmiscml at gmail.com>
> wrote:
> > Hello,
> >
> > On Tue, 12 May 2015 18:38:38 +0000 (UTC)
> > Derek LaHousse <dlahouss at mtu.edu> wrote:
> >
> >> Alexander Stephen Thomas Ross <maillist_arm-netbook <at> aross.me>
> >> writes:
> >>
> >> > really good marketing and a well made original video. however
> >> > they dont give much info like what wifi chipset they use
> >> > -weather its software freedom friendly-.
> >>
> >> From their kickstarter page, it's:
> >> - A realtek 2-in-1 Bluetooth 4.0 + WiFi b/g/n
> >>
> >> Based on that, it's probably an rtl81xx.  Yes, that's a big family
> >> and I don't know any better.  But they all require non-free
> >> firmware.  Bleh.
> >
> > Did you expect anything else?
> >
> >>
> >> The page claims the wifi supports AP mode.  Neat.
> >
> > *Any* wifi chip supports AP mode. Or put in another way, a vendor
> > needs to go out of their way to block it (some do, yeah).
> >
> >
> > --
> > Best regards,
> >  Paul                          mailto:pmiscml at gmail.com



-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com



More information about the arm-netbook mailing list