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@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-... , 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@gmail.com wrote:
Hello,
On Tue, 12 May 2015 18:38:38 +0000 (UTC) Derek LaHousse dlahouss@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@gmail.com
On May 13, 2015 12:07:46 AM GMT+02:00, Paul Sokolovsky pmiscml@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@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-... , 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@gmail.com wrote:
Hello,
On Tue, 12 May 2015 18:38:38 +0000 (UTC) Derek LaHousse dlahouss@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@gmail.com
-- Best regards, Paul mailto:pmiscml@gmail.com
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
THNX, Paul. Entertaining and good info.
GRTNX, RobJE
[ ..Fun stuff..]
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.
Hmm... That's indeed what would happen for a GNU/Linux system, but I thought with Microsoft the user is expected to say either "oh, this adapter sucks" or "damn! what am I doing wrong?" since it wouldn't occur to the user that it could be Microsoft's fault. Of course, that'd be even more true with an Apple product (after all, "it's soo pretty it can't possibly be wrong!").
Stefan
arm-netbook@lists.phcomp.co.uk