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

[Rob J. Epping]

On May 13, 2015 12:07:46 AM GMT+02:00, Paul Sokolovsky <pmiscml at gmail.com> wrote:
>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
>
>_______________________________________________
>arm-netbook mailing list arm-netbook at lists.phcomp.co.uk
>http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
>Send large attachments to arm-netbook at files.phcomp.co.uk

THNX, Paul. Entertaining and good info.

GRTNX, RobJE
-- 
Sent from my mobile device. Please excuse my brevity.