wifi command set secrecy - why?

On 11/27/2021 11:57, Tom Gardner wrote:
> On 27/11/21 03:51, Dimiter_Popoff wrote:
>> On 11/27/2021 1:45, Tom Gardner wrote:
>>> On 26/11/21 22:44, Dimiter_Popoff wrote:
>>>> On 11/27/2021 0:25, Clifford Heath wrote:
>>>>> On 26/11/21 5:40 am, Dimiter_Popoff wrote:
>>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>>> systems and it has turned out it is impossible to get one which is
>>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>>> stack under dps would treat it as yet another medium, like it does
>>>>>> with Ethernet or via PPP and sort of.
>>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>>> was starting there was some PRISM hardware which had been documented;
>>>>>> at some point it was bought and *all* documentation was carefully
>>>>>> made extinct. Now all you can buy are modules which will do the 
>>>>>> tcp/ip
>>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>>> maintain etc.
>>>>>> Why is that, does anybody know? I am trying to understand the 
>>>>>> motivation
>>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>>> if I once understand it I can advance a step closer. I am really
>>>>>> reluctant to spend a year of my life writing my firmware for
>>>>>> some wifi radio (these can be bought), not least because I have 
>>>>>> better
>>>>>> things to do with the active years I can hope to have left.
>>>>>
>>>>> I believe that there is a fair amount of trade secrecy in making 
>>>>> WiFi chipsets, and they're trying to protect their advantages from 
>>>>> other manufacturers. Broadcom has been a standout performer in the 
>>>>> sekrit sauce club.
>>>>
>>>> This is quite likely the case (being competitive), but the firmware
>>>> command protocols?... I don't think it is possible they don't know
>>>> each other's protocols, could well be they use the same or very similar
>>>> ones. If they hide things from each other it will be in the dsp-ing
>>>> parts and sort of, where they can get a performance advantage.
>>>
>>> There are other possibilities...
>>>
>>> Price and power consumption are important. Certainly in the
>>> wired interface arena a quarter of a century ago there was
>>> secret sauce in how you divided MAC and packet level processing
>>> between the various processors. Many unfortunate choices were
>>> made at that time.
>>
>> The first Ethernet chip I used, the "SONIC" from NSC, introduced
>> in the early 90-s (or was it late 80-s), was completely documented,
>> never had to look beyond its datasheet to use it. The Motorola
>> parts with MACs were were also documented as far as I have
>> noticed (never used any of them). You must be talking about
>> some other "world" (PC?) I am not familiar with, but in my
>> world things were documented as usual.
> 
> I was thinking of workstation networking, and for
> more than ethernet.
> 
> Back then it was a pre-Cambian explosion of technologies,
> 802.11 wasn't yet on the horizon, and XTP was a
> proposed replacement for TCP since it was wrongly
> believed that TCP limited userspace-to-userspace
> bandwidth. The limitation was poor implementations
> of the networking stack.

This is another world to me, I don't even know what XTP is
(but my tcp/ip implementation works OK :).

> 
>>> Then there's the possible issue that they don't want to let
>>> miscreants easily change RF parameters, since that would enable
>>> them to commit all sorts of RF sins. Security through obscurity
>>> is better than nothing, although maybe they use stronger
>>> techniques.
>>
>> This sounds like a credible excuse but it does not explain
>> why also all the embedded wifi modules are so strict about not
>> allowing you to do IP packets, you *must* go through their
>> tcp/ip stack. Surely you cannot do any RF-evil by doing
>> IP packets and being unable to tinker with the radio.
> 
> There might be other antisocial sins, e.g. DOS attacks, but
> these are only conceptions. A lot will depend on system
> partitioning and implementations.
> 
> But it is only speculation.

Wifi is not the best choice for rogue IP level behaviour,
there is optical broadband and whatnot. I don't think it is this,
may be something related I can't think of.

> 
> 
>>> Also, impeding reverse engineering allows them to have more
>>> leverage w.r.t. licencing their technology, especially if
>>> drivers are only issued in the form of big blobs of optimised
>>> code.
>>
>> This can be some motivation for them but it still does not
>> explain the "no IP packets" policy, which is the bizarre
>> part of it all and which is likely driven by what drives
>> the secrecy I am wondering about. And if we all can only
>> speculate about the *why* obviously it is very very serious.
> 
> It might also allow manufacturers to hide bugs and to
> re-partition functionality over time. A lot will depend
> on what interfaces they want to guarantee stable and
> correct over time.
> 
> Is any of that a justification? No. But there might
> be some respectable reasons hidden in there.

Well it definitely looks that they put more effort into
keeping a lid on it than they would have to otherwise.
Now they have to implement a tcp/ip stack, let you order
what connections to make, maintain them and provide an
interface for you to use these connections in a viable
manner.
It is much easier to just hand you the IP layer and let
you do the connections, at least someone would have been
tempted to try to reach a market segment with such a
simplified product - but there is none, clearly there is
some policy impediment we do not understand....

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

lørdag den 27. november 2021 kl. 00.45.08 UTC+1 skrev Tom Gardner:
> On 26/11/21 22:44, Dimiter_Popoff wrote: 
> > On 11/27/2021 0:25, Clifford Heath wrote: 
> >> On 26/11/21 5:40 am, Dimiter_Popoff wrote: 
> >>> I have been looking for some wifi chip(set) to be able to use in our 
> >>> systems and it has turned out it is impossible to get one which is 
> >>> documented in a way we could write our own driver so our tcp/ip 
> >>> stack under dps would treat it as yet another medium, like it does 
> >>> with Ethernet or via PPP and sort of. 
> >>> What I don't get is *why* do they keep things so secret? When wifi 
> >>> was starting there was some PRISM hardware which had been documented; 
> >>> at some point it was bought and *all* documentation was carefully 
> >>> made extinct. Now all you can buy are modules which will do the tcp/ip 
> >>> for you, you can only ask for a tcp connection *they* will make and 
> >>> maintain etc. 
> >>> Why is that, does anybody know? I am trying to understand the motivation 
> >>> of those who pull the strings to keep these data so secret, perhaps 
> >>> if I once understand it I can advance a step closer. I am really 
> >>> reluctant to spend a year of my life writing my firmware for 
> >>> some wifi radio (these can be bought), not least because I have better 
> >>> things to do with the active years I can hope to have left. 
> >> 
> >> I believe that there is a fair amount of trade secrecy in making WiFi 
> >> chipsets, and they're trying to protect their advantages from other 
> >> manufacturers. Broadcom has been a standout performer in the sekrit sauce club. 
> > 
> > This is quite likely the case (being competitive), but the firmware 
> > command protocols?... I don't think it is possible they don't know 
> > each other's protocols, could well be they use the same or very similar 
> > ones. If they hide things from each other it will be in the dsp-ing 
> > parts and sort of, where they can get a performance advantage.
> There are other possibilities... 
> 
> Price and power consumption are important. Certainly in the 
> wired interface arena a quarter of a century ago there was 
> secret sauce in how you divided MAC and packet level processing 
> between the various processors. Many unfortunate choices were 
> made at that time. 
> 
> Then there's the possible issue that they don't want to let 
> miscreants easily change RF parameters, since that would enable 
> them to commit all sorts of RF sins. Security through obscurity 
> is better than nothing, although maybe they use stronger 
> techniques. 

seems to remember sometime ago FCC started to complain about routers 
being able to run unsigned opensource firmware, because it enabled 
people to change frequencies, powerlevels, etc. and not comply 
with the certification

 

On 27/11/21 12:56, Lasse Langwadt Christensen wrote:
> lørdag den 27. november 2021 kl. 00.45.08 UTC+1 skrev Tom Gardner:
>> On 26/11/21 22:44, Dimiter_Popoff wrote:
>>> On 11/27/2021 0:25, Clifford Heath wrote:
>>>> On 26/11/21 5:40 am, Dimiter_Popoff wrote:
>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>> systems and it has turned out it is impossible to get one which is
>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>> stack under dps would treat it as yet another medium, like it does
>>>>> with Ethernet or via PPP and sort of.
>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>> was starting there was some PRISM hardware which had been documented;
>>>>> at some point it was bought and *all* documentation was carefully
>>>>> made extinct. Now all you can buy are modules which will do the tcp/ip
>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>> maintain etc.
>>>>> Why is that, does anybody know? I am trying to understand the motivation
>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>> if I once understand it I can advance a step closer. I am really
>>>>> reluctant to spend a year of my life writing my firmware for
>>>>> some wifi radio (these can be bought), not least because I have better
>>>>> things to do with the active years I can hope to have left.
>>>>
>>>> I believe that there is a fair amount of trade secrecy in making WiFi
>>>> chipsets, and they're trying to protect their advantages from other
>>>> manufacturers. Broadcom has been a standout performer in the sekrit sauce club.
>>>
>>> This is quite likely the case (being competitive), but the firmware
>>> command protocols?... I don't think it is possible they don't know
>>> each other's protocols, could well be they use the same or very similar
>>> ones. If they hide things from each other it will be in the dsp-ing
>>> parts and sort of, where they can get a performance advantage.
>> There are other possibilities...
>>
>> Price and power consumption are important. Certainly in the
>> wired interface arena a quarter of a century ago there was
>> secret sauce in how you divided MAC and packet level processing
>> between the various processors. Many unfortunate choices were
>> made at that time.
>>
>> Then there's the possible issue that they don't want to let
>> miscreants easily change RF parameters, since that would enable
>> them to commit all sorts of RF sins. Security through obscurity
>> is better than nothing, although maybe they use stronger
>> techniques.
> 
> seems to remember sometime ago FCC started to complain about routers
> being able to run unsigned opensource firmware, because it enabled
> people to change frequencies, powerlevels, etc. and not comply
> with the certification

I predicted something similar last millennium, and patented
a way to make it much more difficult to achieve.

On 26/11/2021 20.50, Dimiter_Popoff wrote:
> On 11/26/2021 20:51, Carlos E.R. wrote:
>> On 26/11/2021 13.06, Dimiter_Popoff wrote:
>>> On 11/26/2021 12:27, Carlos E.R. wrote:
>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote:
>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>> systems and it has turned out it is impossible to get one which is
>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>> stack under dps would treat it as yet another medium, like it does
>>>>> with Ethernet or via PPP and sort of.
>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>> was starting there was some PRISM hardware which had been documented;
>>>>> at some point it was bought and *all* documentation was carefully
>>>>> made extinct. Now all you can buy are modules which will do the tcp/ip
>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>> maintain etc.
>>>>> Why is that, does anybody know? I am trying to understand the 
>>>>> motivation
>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>> if I once understand it I can advance a step closer. I am really
>>>>> reluctant to spend a year of my life writing my firmware for
>>>>> some wifi radio (these can be bought), not least because I have better
>>>>> things to do with the active years I can hope to have left.
>>>>
>>>> Have a look at the Linux driver if it exists. They usually 
>>>> reverse-engineer the needed specs.
>>>>
>>>
>>> These drivers are not open source, not for the part that matters.
>>> The reverse engineered part is available IIRC, but what I try to
>>> understand is *why* do they (and I) have to reverse engineer
>>> what the likes of microsoft and android makers have access to.
>>
>> The Linux drivers are open source (whether they are documented enough 
>> or what you want, is another matter).
>> If the makers do their own closed source driver for Linux, that's 
>> their driver, not the Linux driver.
> 
> All wifi chipsets I have seen - and I have probably looked at any maker
> over the years - are quite explicit they come with "drivers for windows,
> Linux" etc. These drivers are what talks to the firmware of course,
> which is what the secrecy is about.

But Linux doesn't use those drivers, that's my point.

All drivers in the Linux kernel must be added in source form. Binaries 
are not accepted.

...

-- 
Cheers, Carlos.

On 11/28/2021 15:02, Carlos E.R. wrote:
> On 26/11/2021 20.50, Dimiter_Popoff wrote:
>> On 11/26/2021 20:51, Carlos E.R. wrote:
>>> On 26/11/2021 13.06, Dimiter_Popoff wrote:
>>>> On 11/26/2021 12:27, Carlos E.R. wrote:
>>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote:
>>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>>> systems and it has turned out it is impossible to get one which is
>>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>>> stack under dps would treat it as yet another medium, like it does
>>>>>> with Ethernet or via PPP and sort of.
>>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>>> was starting there was some PRISM hardware which had been documented;
>>>>>> at some point it was bought and *all* documentation was carefully
>>>>>> made extinct. Now all you can buy are modules which will do the 
>>>>>> tcp/ip
>>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>>> maintain etc.
>>>>>> Why is that, does anybody know? I am trying to understand the 
>>>>>> motivation
>>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>>> if I once understand it I can advance a step closer. I am really
>>>>>> reluctant to spend a year of my life writing my firmware for
>>>>>> some wifi radio (these can be bought), not least because I have 
>>>>>> better
>>>>>> things to do with the active years I can hope to have left.
>>>>>
>>>>> Have a look at the Linux driver if it exists. They usually 
>>>>> reverse-engineer the needed specs.
>>>>>
>>>>
>>>> These drivers are not open source, not for the part that matters.
>>>> The reverse engineered part is available IIRC, but what I try to
>>>> understand is *why* do they (and I) have to reverse engineer
>>>> what the likes of microsoft and android makers have access to.
>>>
>>> The Linux drivers are open source (whether they are documented enough 
>>> or what you want, is another matter).
>>> If the makers do their own closed source driver for Linux, that's 
>>> their driver, not the Linux driver.
>>
>> All wifi chipsets I have seen - and I have probably looked at any maker
>> over the years - are quite explicit they come with "drivers for windows,
>> Linux" etc. These drivers are what talks to the firmware of course,
>> which is what the secrecy is about.
> 
> But Linux doesn't use those drivers, that's my point.
> 
> All drivers in the Linux kernel must be added in source form. Binaries 
> are not accepted.
> 
> ...
> 

Wherever the binaries for the wifi chipsets are added they are not
open source, that much is obvious. Without these binaries linux can
run - without wifi.
Had there been any useful sources I would have seen them long ago.

søndag den 28. november 2021 kl. 14.52.10 UTC+1 skrev Dimiter Popoff:
> On 11/28/2021 15:02, Carlos E.R. wrote: 
> > On 26/11/2021 20.50, Dimiter_Popoff wrote: 
> >> On 11/26/2021 20:51, Carlos E.R. wrote: 
> >>> On 26/11/2021 13.06, Dimiter_Popoff wrote: 
> >>>> On 11/26/2021 12:27, Carlos E.R. wrote: 
> >>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote: 
> >>>>>> I have been looking for some wifi chip(set) to be able to use in our 
> >>>>>> systems and it has turned out it is impossible to get one which is 
> >>>>>> documented in a way we could write our own driver so our tcp/ip 
> >>>>>> stack under dps would treat it as yet another medium, like it does 
> >>>>>> with Ethernet or via PPP and sort of. 
> >>>>>> What I don't get is *why* do they keep things so secret? When wifi 
> >>>>>> was starting there was some PRISM hardware which had been documented; 
> >>>>>> at some point it was bought and *all* documentation was carefully 
> >>>>>> made extinct. Now all you can buy are modules which will do the 
> >>>>>> tcp/ip 
> >>>>>> for you, you can only ask for a tcp connection *they* will make and 
> >>>>>> maintain etc. 
> >>>>>> Why is that, does anybody know? I am trying to understand the 
> >>>>>> motivation 
> >>>>>> of those who pull the strings to keep these data so secret, perhaps 
> >>>>>> if I once understand it I can advance a step closer. I am really 
> >>>>>> reluctant to spend a year of my life writing my firmware for 
> >>>>>> some wifi radio (these can be bought), not least because I have 
> >>>>>> better 
> >>>>>> things to do with the active years I can hope to have left. 
> >>>>> 
> >>>>> Have a look at the Linux driver if it exists. They usually 
> >>>>> reverse-engineer the needed specs. 
> >>>>> 
> >>>> 
> >>>> These drivers are not open source, not for the part that matters. 
> >>>> The reverse engineered part is available IIRC, but what I try to 
> >>>> understand is *why* do they (and I) have to reverse engineer 
> >>>> what the likes of microsoft and android makers have access to. 
> >>> 
> >>> The Linux drivers are open source (whether they are documented enough 
> >>> or what you want, is another matter). 
> >>> If the makers do their own closed source driver for Linux, that's 
> >>> their driver, not the Linux driver. 
> >> 
> >> All wifi chipsets I have seen - and I have probably looked at any maker 
> >> over the years - are quite explicit they come with "drivers for windows, 
> >> Linux" etc. These drivers are what talks to the firmware of course, 
> >> which is what the secrecy is about. 
> > 
> > But Linux doesn't use those drivers, that's my point. 
> > 
> > All drivers in the Linux kernel must be added in source form. Binaries 
> > are not accepted. 
> > 
> > ... 
> >
> Wherever the binaries for the wifi chipsets are added they are not 
> open source, that much is obvious. Without these binaries linux can 
> run - without wifi. 
> Had there been any useful sources I would have seen them long ago.

looks like there is a few that doesn't require a binaryblob

https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers

On 11/28/2021 15:58, Lasse Langwadt Christensen wrote:
> søndag den 28. november 2021 kl. 14.52.10 UTC+1 skrev Dimiter Popoff:
>> On 11/28/2021 15:02, Carlos E.R. wrote:
>>> On 26/11/2021 20.50, Dimiter_Popoff wrote:
>>>> On 11/26/2021 20:51, Carlos E.R. wrote:
>>>>> On 26/11/2021 13.06, Dimiter_Popoff wrote:
>>>>>> On 11/26/2021 12:27, Carlos E.R. wrote:
>>>>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote:
>>>>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>>>>> systems and it has turned out it is impossible to get one which is
>>>>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>>>>> stack under dps would treat it as yet another medium, like it does
>>>>>>>> with Ethernet or via PPP and sort of.
>>>>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>>>>> was starting there was some PRISM hardware which had been documented;
>>>>>>>> at some point it was bought and *all* documentation was carefully
>>>>>>>> made extinct. Now all you can buy are modules which will do the
>>>>>>>> tcp/ip
>>>>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>>>>> maintain etc.
>>>>>>>> Why is that, does anybody know? I am trying to understand the
>>>>>>>> motivation
>>>>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>>>>> if I once understand it I can advance a step closer. I am really
>>>>>>>> reluctant to spend a year of my life writing my firmware for
>>>>>>>> some wifi radio (these can be bought), not least because I have
>>>>>>>> better
>>>>>>>> things to do with the active years I can hope to have left.
>>>>>>>
>>>>>>> Have a look at the Linux driver if it exists. They usually
>>>>>>> reverse-engineer the needed specs.
>>>>>>>
>>>>>>
>>>>>> These drivers are not open source, not for the part that matters.
>>>>>> The reverse engineered part is available IIRC, but what I try to
>>>>>> understand is *why* do they (and I) have to reverse engineer
>>>>>> what the likes of microsoft and android makers have access to.
>>>>>
>>>>> The Linux drivers are open source (whether they are documented enough
>>>>> or what you want, is another matter).
>>>>> If the makers do their own closed source driver for Linux, that's
>>>>> their driver, not the Linux driver.
>>>>
>>>> All wifi chipsets I have seen - and I have probably looked at any maker
>>>> over the years - are quite explicit they come with "drivers for windows,
>>>> Linux" etc. These drivers are what talks to the firmware of course,
>>>> which is what the secrecy is about.
>>>
>>> But Linux doesn't use those drivers, that's my point.
>>>
>>> All drivers in the Linux kernel must be added in source form. Binaries
>>> are not accepted.
>>>
>>> ...
>>>
>> Wherever the binaries for the wifi chipsets are added they are not
>> open source, that much is obvious. Without these binaries linux can
>> run - without wifi.
>> Had there been any useful sources I would have seen them long ago.
> 
> looks like there is a few that doesn't require a binaryblob
> 
> https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers
> 

This looks promising, I had not chased these ghosts for a while.
Thanks.

On 28/11/2021 14.52, Dimiter_Popoff wrote:
> On 11/28/2021 15:02, Carlos E.R. wrote:
>> On 26/11/2021 20.50, Dimiter_Popoff wrote:
>>> On 11/26/2021 20:51, Carlos E.R. wrote:
>>>> On 26/11/2021 13.06, Dimiter_Popoff wrote:
>>>>> On 11/26/2021 12:27, Carlos E.R. wrote:
>>>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote:
>>>>>>> I have been looking for some wifi chip(set) to be able to use in our
>>>>>>> systems and it has turned out it is impossible to get one which is
>>>>>>> documented in a way we could write our own driver so our tcp/ip
>>>>>>> stack under dps would treat it as yet another medium, like it does
>>>>>>> with Ethernet or via PPP and sort of.
>>>>>>> What I don't get is *why* do they keep things so secret? When wifi
>>>>>>> was starting there was some PRISM hardware which had been 
>>>>>>> documented;
>>>>>>> at some point it was bought and *all* documentation was carefully
>>>>>>> made extinct. Now all you can buy are modules which will do the 
>>>>>>> tcp/ip
>>>>>>> for you, you can only ask for a tcp connection *they* will make and
>>>>>>> maintain etc.
>>>>>>> Why is that, does anybody know? I am trying to understand the 
>>>>>>> motivation
>>>>>>> of those who pull the strings to keep these data so secret, perhaps
>>>>>>> if I once understand it I can advance a step closer. I am really
>>>>>>> reluctant to spend a year of my life writing my firmware for
>>>>>>> some wifi radio (these can be bought), not least because I have 
>>>>>>> better
>>>>>>> things to do with the active years I can hope to have left.
>>>>>>
>>>>>> Have a look at the Linux driver if it exists. They usually 
>>>>>> reverse-engineer the needed specs.
>>>>>>
>>>>>
>>>>> These drivers are not open source, not for the part that matters.
>>>>> The reverse engineered part is available IIRC, but what I try to
>>>>> understand is *why* do they (and I) have to reverse engineer
>>>>> what the likes of microsoft and android makers have access to.
>>>>
>>>> The Linux drivers are open source (whether they are documented 
>>>> enough or what you want, is another matter).
>>>> If the makers do their own closed source driver for Linux, that's 
>>>> their driver, not the Linux driver.
>>>
>>> All wifi chipsets I have seen - and I have probably looked at any maker
>>> over the years - are quite explicit they come with "drivers for windows,
>>> Linux" etc. These drivers are what talks to the firmware of course,
>>> which is what the secrecy is about.
>>
>> But Linux doesn't use those drivers, that's my point.
>>
>> All drivers in the Linux kernel must be added in source form. Binaries 
>> are not accepted.
>>
>> ...
>>
> 
> Wherever the binaries for the wifi chipsets are added they are not
> open source, that much is obvious. Without these binaries linux can
> run - without wifi.

Not true. I run Linux without any binary only wifi driver.

> Had there been any useful sources I would have seen them long ago.

Then you didn't look deep enough...


-- 
Cheers, Carlos.

On 11/25/2021 11:40 AM, Dimiter_Popoff wrote:

[WiFi chipset docs UNavailability]

> What I don't get is *why* do they keep things so secret? When wifi
> was starting there was some PRISM hardware which had been documented;
> at some point it was bought and *all* documentation was carefully
> made extinct. Now all you can buy are modules which will do the tcp/ip
> for you, you can only ask for a tcp connection *they* will make and
> maintain etc.

The obvious answer, of course, is because they don't HAVE to disclose
that information in order to keep/gain market share.  Chances are,
a huge portion of their sales go to a few customers.  They can
engage directly with those customers (and, likely, have done so BEFORE
even committing to a design -- likely with input from those customers!)
in "special relationships" where they exchange technical details
AND BUSINESS PLANS with each other (you're not likely going to give
much cred to a customer without knowing/believing that he will be
a BIG buyer!  "Prove it!")

If they're first on the market (or, "novel" in some other way), then
they can keep slightly ahead of competitors, for a short while, by
closely guarding all of the details of their tech.  This can often be
enough to make a big difference as you can get "design-ins" and lock
customers into your product before the competitor has another offering.

You'd not want a competitor to create a "drop in" replacement after
you've created the market!

[Recall CPU vendors protecting the actual mnemonics that they used in
their ASM languages!  What value, that?  Enough to justify the
effort to do so??]

Often, they are expecting to only deal with "big" customers. Keeping things 
under NDAs (the parties to which THEY control) means they can focus on the
needs of those customers, instead of the "small potatoes".  It may even
be the case that some of those customers contribute software to support
the product thereafter (likely on the condition that it not be released
to others IN SOURCE FORM -- thereby giving the original creator an advantage
as they can modify/enhance the code while others are still trying to
create it from scratch).  Or, that some hooks into the device are made
known to those customers but not other customers.

Because they impose an NDA, they can decide *who* they're willing to
engage with an NDA and who's "too small".

[I've had companies refuse to deal with me as an individual.  But,
have my CLIENT call and ask for a quote on a few hundred thousand
pieces and suddenly they're interested!  "Please send the quote to
Don at..."  :>   Ooops!]

The design may change -- often.  They can then decide how those changes
are seen.  E.g., if they offer a software middleware layer, then they
can bury the changes in the middleware without ever "burdening" their
(large, precious!) customers with exposed changes.

[NatSemi hid a lot of the bugs in their 32K silicon behind their own
compiler.  Given that there were few other compiler offerings -- for
their silicon -- on the market, this seemed a safe bet, all 'round.]

Fewer eyes to critique the documents (to which they'd have to respond).

Market research -- they KNOW how many (and who!) folks are actually
interested in their product offering and *how* interested they actually
are ("bingo card" vs. ready-to-have-a-corporate-lawyer-sign-off-on-NDA).
And, the potential sales volumes for each customer.

Market commitment -- they can withdraw the product if it doesn't suit
their expectations and only have limited/known obligations.

There were gazillions of 2A03s sold.  But, try to find a supporting
toolchain from that era!

I have several "numbered" documents "Do Not Copy", "Do Not Destroy", etc.
accumulated over the years.  And, all sorts of engineering samples that
don't even have real part numbers (cuz the parts weren't formally
announced at the time the silicon was made available to me).  As far
as the rest of the world is concerned, these devices never existed
(cuz they never made it to formal release)

I've also documents that define undefined aspects of COTS devices that
the vendors opted not to specify in their datasheets (thinking there
was no interest in those details) -- but, would be willing to disclose
to very large customers.

Try to find information on the bitstream format for FPGA initialization.

Or, the "secure boot" modes on modern processors.

Or...

Clearly, there are people with access to this information.  Just "selectively"
chosen!

Your options are to find something that knows how to talk to <whatever>
and then find a way of talking to THAT.  Or, reverse engineer a driver
to a "visible" implementation.  Or, consider some other communications
medium (BT?  ZigBee?  etc.) that is more accessible.

On Sunday, November 28, 2021 at 5:08:13 PM UTC-4, Carlos E.R. wrote:
> On 28/11/2021 14.52, Dimiter_Popoff wrote: 
> > On 11/28/2021 15:02, Carlos E.R. wrote: 
> >> On 26/11/2021 20.50, Dimiter_Popoff wrote: 
> >>> On 11/26/2021 20:51, Carlos E.R. wrote: 
> >>>> On 26/11/2021 13.06, Dimiter_Popoff wrote: 
> >>>>> On 11/26/2021 12:27, Carlos E.R. wrote: 
> >>>>>> On 25/11/2021 19.40, Dimiter_Popoff wrote: 
> >>>>>>> I have been looking for some wifi chip(set) to be able to use in our 
> >>>>>>> systems and it has turned out it is impossible to get one which is 
> >>>>>>> documented in a way we could write our own driver so our tcp/ip 
> >>>>>>> stack under dps would treat it as yet another medium, like it does 
> >>>>>>> with Ethernet or via PPP and sort of. 
> >>>>>>> What I don't get is *why* do they keep things so secret? When wifi 
> >>>>>>> was starting there was some PRISM hardware which had been 
> >>>>>>> documented; 
> >>>>>>> at some point it was bought and *all* documentation was carefully 
> >>>>>>> made extinct. Now all you can buy are modules which will do the 
> >>>>>>> tcp/ip 
> >>>>>>> for you, you can only ask for a tcp connection *they* will make and 
> >>>>>>> maintain etc. 
> >>>>>>> Why is that, does anybody know? I am trying to understand the 
> >>>>>>> motivation 
> >>>>>>> of those who pull the strings to keep these data so secret, perhaps 
> >>>>>>> if I once understand it I can advance a step closer. I am really 
> >>>>>>> reluctant to spend a year of my life writing my firmware for 
> >>>>>>> some wifi radio (these can be bought), not least because I have 
> >>>>>>> better 
> >>>>>>> things to do with the active years I can hope to have left. 
> >>>>>> 
> >>>>>> Have a look at the Linux driver if it exists. They usually 
> >>>>>> reverse-engineer the needed specs. 
> >>>>>> 
> >>>>> 
> >>>>> These drivers are not open source, not for the part that matters. 
> >>>>> The reverse engineered part is available IIRC, but what I try to 
> >>>>> understand is *why* do they (and I) have to reverse engineer 
> >>>>> what the likes of microsoft and android makers have access to. 
> >>>> 
> >>>> The Linux drivers are open source (whether they are documented 
> >>>> enough or what you want, is another matter). 
> >>>> If the makers do their own closed source driver for Linux, that's 
> >>>> their driver, not the Linux driver. 
> >>> 
> >>> All wifi chipsets I have seen - and I have probably looked at any maker 
> >>> over the years - are quite explicit they come with "drivers for windows, 
> >>> Linux" etc. These drivers are what talks to the firmware of course, 
> >>> which is what the secrecy is about. 
> >> 
> >> But Linux doesn't use those drivers, that's my point. 
> >> 
> >> All drivers in the Linux kernel must be added in source form. Binaries 
> >> are not accepted. 
> >> 
> >> ... 
> >> 
> > 
> > Wherever the binaries for the wifi chipsets are added they are not 
> > open source, that much is obvious. Without these binaries linux can 
> > run - without wifi.
> Not true. I run Linux without any binary only wifi driver.
> > Had there been any useful sources I would have seen them long ago.
> Then you didn't look deep enough... 

So there are wifi drivers under Linux for only certain chips?  If I buy a laptop intending to run Linux I need to know whether the wifi chip is supported or not, yes? 

-- 

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209