wifi command set secrecy - why?...

[Tom Gardner]

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.

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.

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.

 

[Dimiter_Popoff]

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/

 

[Lasse Langwadt Christensen]

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

 

[Tom Gardner]

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.

 

[Carlos E.R.]

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.

 

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

 

[Lasse Langwadt Christensen]

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

 

[Dimiter_Popoff]

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.

 

[Carlos E.R.]

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.

 

[Don Y]

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.

 

[Rick C]

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

 

[Gerhard Hoffmann]

Am 28.11.21 um 22:19 schrieb Rick C:

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:

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.

The drivers are not part of the the kernel.

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.

So what. I run Linux with a binary only Nvidia graphics driver.
The reverse-engineered attempt called Nouveau does not cut it.

Gerhard

 

[Dimiter_Popoff]

On 11/28/2021 23:19, Rick C wrote:

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?

Generally no, it is just that some (as it appears, I have yet to dig
through that again) have \"binaries\" (closed source) parts.
The list Lasse posted a link to suggests there are wifi modules with
completely open source firmware interfaces (but I have yet to dig
there, I still find it hard to believe there are driver sources
and zero documentation online on what was needed to write these
drivers).

 

[Rick C]

On Sunday, November 28, 2021 at 5:32:34 PM UTC-4, Gerhard Hoffmann wrote:

Am 28.11.21 um 22:19 schrieb Rick C:
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:


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.
The drivers are not part of the the kernel.

Then how does the kernel communicate with the user?

--

Rick C.

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

 

[Rick C]

On Sunday, November 28, 2021 at 6:56:15 PM UTC-4, Dimiter Popoff wrote:

On 11/28/2021 23:19, Rick C wrote:
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:

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?

Generally no, it is just that some (as it appears, I have yet to dig
through that again) have \"binaries\" (closed source) parts.
The list Lasse posted a link to suggests there are wifi modules with
completely open source firmware interfaces (but I have yet to dig
there, I still find it hard to believe there are driver sources
and zero documentation online on what was needed to write these
drivers).

Then the answer is YES because I would otherwise be taking a risk of buying a laptop with no Linux drivers... well, no open source drivers. Do any graphics chips not provide a binary blob for Linux? Are they typically bug free? I guess that\'s a stupid question.

--

Rick C.

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

 

[bilou]

Le 25/11/2021 à 19:40, Dimiter_Popoff a écrit :

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.

Having total control of devices radiating RF would be a nightmare
There will be lots of jammers and out of band usage.