Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

where can i find a list of wireless adapter that debian support

39 views
Skip to first unread message

loushan...@sina.com

unread,
Jul 19, 2021, 3:50:04 AM7/19/21
to

i hate to install firmware from non-free section
in some instances free adapter perform better than non-free one

i browse some e-shop, some vendor claim that you needn't driver for their adapter installation
i guess driver is included somewhere in adapter, vendor say they can be installed in Windows
after all chinese desktop market is dominated by Windows
it's very difficult to install them in linux
some web site offer instruction on how to install them in linux  


Georgi Naplatanov

unread,
Jul 19, 2021, 6:30:05 AM7/19/21
to
Hi,

I haven't seen database with supported WiFi network cards for Linux but
if you have liked a particular WiFi adapter then you can search on
Internet to check if it's supported or not.

Another option is to test particular device with live image.

Kind regards
Georgi

loushan...@sina.com

unread,
Jul 19, 2021, 8:40:05 AM7/19/21
to
Thanks, mick!
i've found some adapter with search engine
hopefully it can be installed in debian without firmware from non-free

Andrew M.A. Cater

unread,
Jul 19, 2021, 8:50:05 AM7/19/21
to
On Mon, Jul 19, 2021 at 08:32:39PM +0800, loushan...@sina.com wrote:
> Thanks, mick!
> i've found some adapter with search enginehopefully it can be installed in debian without firmware from non-free
>

It's fairly unlikely that any modern adapter will work with no non-free
firmware: there's too many binary blobs and pieces for regulatory compliance.

It is also sometimes true that the only source of firmware is by building
something from Github - that is pore problematic.

Good luck in the search.

All the very best,

Andy Cater

Stefan Monnier

unread,
Jul 19, 2021, 9:40:04 AM7/19/21
to
loushan...@sina.com [2021-07-19 20:32:39] wrote:
> i've found some adapter with search enginehopefully it can be installed in
> debian without firmware from non-free

AFAIK there is currently no wifi card that supports 11ac and for which
there exists a non-proprietary firmware.


Stefan

loushan...@sina.com

unread,
Jul 20, 2021, 5:10:05 AM7/20/21
to
Thank Andrew, Stefan and nick!
i prefer old wifi adapter if new one often requires non-free firmware
it seems that Windows is better supported than linux in this aspect
finding my ideal adapter with right interface isn't easy
(usb is preferred, some pci card can't be install in my PC)
finding them at reasonable price on Chinese market isn't easy
i may have to give up, i have to put up with non-free firmware

Christian Britz

unread,
Jul 20, 2021, 5:30:05 AM7/20/21
to


At 20.07.21 11:01 loushan...@sina.com wrote:
> Thank Andrew, Stefan and nick!
> i prefer old wifi adapter if new one often requires non-free firmware
> it seems that Windows is better supported than linux in this aspect

On Windows, everything regarding the driver is non-free, not only the
firmware.
Personally I can live with non-free firmware and have always enabled this.

loushan...@sina.com

unread,
Jul 20, 2021, 5:50:04 AM7/20/21
to
Christian Britz wrote:
On Windows, everything regarding the driver is non-free, not only the
firmware.
Personally I can live with non-free firmware and have always enabled this.

Windows is better supported because many vendors claim they support Windows from winxp to win10
they don't mention linux 

Ubuntu is more friendly than debian in this case, it just install them(including non-free firmware), hiding ugly details from user

Joe

unread,
Jul 20, 2021, 8:10:04 AM7/20/21
to
On Tue, 20 Jul 2021 17:47:21 +0800
<loushan...@sina.com> wrote:


> Windows is better supported because many vendors claim they support
> Windows from winxp to win10they don't mention linux
>
This is because all PC hardware is *designed* to work with current,
recent and near-future versions of Windows, because the manufacturer
would have no market for his products otherwise. It is more profitable
to ignore a few percent of the potential customers than to double the
development and testing effort.

--
Joe

loushan...@sina.com

unread,
Jul 22, 2021, 1:00:07 AM7/22/21
to
Thank Georgi!

the tricky part of my search for ideal adapter(needn't non-free firmware) is
that many vendors claim they support linux, but i'm afraid they require non-free firmware

is there some easy way to find out if it requires non-free firmware?

Gene Heskett

unread,
Jul 22, 2021, 4:40:05 AM7/22/21
to
On Thursday 22 July 2021 00:58:23 loushan...@sina.com wrote:

> Thank Georgi!
> the tricky part of my search for ideal adapter(needn't non-free
> firmware) isthat many vendors claim they support linux, but i'm afraid
> they require non-free firmware is there some easy way to find out if
> it requires non-free firmware?

I'll repeat why you will find there is a 100% need for sealed blobs of
firmware. Because the FCC requires that the frequencies used be limited
to the assigned band for this service, and the power outputs are also
limited, these are options for software radios, must be enforced with
with code whose limits are not accessable to the user. So all code that
manages this, is by the rules, sealed code, and the radio doesn't work
w/o it.

Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

loushan...@sina.com

unread,
Jul 22, 2021, 6:10:05 AM7/22/21
to

Thank Gene, i'd better give up search for ideal wireless  adapter

my old pci wireless adapter needn't non-free firmware, but new adapter need, as Andrew has said


Andrei POPESCU

unread,
Jul 23, 2021, 3:30:04 AM7/23/21
to
On Jo, 22 iul 21, 04:33:09, Gene Heskett wrote:
> On Thursday 22 July 2021 00:58:23 loushan...@sina.com wrote:
>
> > Thank Georgi!
> > the tricky part of my search for ideal adapter(needn't non-free
> > firmware) isthat many vendors claim they support linux, but i'm afraid
> > they require non-free firmware is there some easy way to find out if
> > it requires non-free firmware?
>
> I'll repeat why you will find there is a 100% need for sealed blobs of
> firmware. Because the FCC requires that the frequencies used be limited
> to the assigned band for this service, and the power outputs are also
> limited, these are options for software radios, must be enforced with
> with code whose limits are not accessable to the user. So all code that
> manages this, is by the rules, sealed code, and the radio doesn't work
> w/o it.

Sure.

On the other hand, if the device would accept only firmware signed by
the manufacturer the code itself could be open sourced.

Users would still depend on the manufacturers to actually release
updates, but at least they would have a way to contribute improvements
to the code.

Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc

loushan...@sina.com

unread,
Jul 23, 2021, 5:30:05 AM7/23/21
to

Thanks, as most adapters require firmware, it's not handy for user to supply them during installation

can't debian do a better job? i care more about ease of use than freeware philosophy
many other distro just supply them

these non-free firmware are same as software without source code??

Dan Ritter

unread,
Jul 23, 2021, 5:40:05 AM7/23/21
to
loushan...@sina.com wrote:
>
> Thanks, as most adapters require firmware, it's not handy for user to supply them during installation
> can't debian do a better job? i care more about ease of use than freeware philosophymany other distro just supply them

If all distros were the same, why would we have more than one?

Debian cares enough about software freedom to make you jump
through a hoop on this issue, but not so much that finding the
hoop is impossible.

In this case, activating the non-free repository in /etc/apt/sources.list
is the hoop.

> these non-free firmware are same as software without source code??

They aren't the complete driver, but rather a chunk of software that
runs on the device itself. The manufacturer does not supply the source
code for that, but allows the binary object to be distributed. It is
called firmware because it is between software and hardware.

-dsr-

to...@tuxteam.de

unread,
Jul 23, 2021, 5:50:05 AM7/23/21
to
On Fri, Jul 23, 2021 at 05:11:25PM +0800, loushan...@sina.com wrote:
>
> Thanks, as most adapters require firmware, it's not handy for user to supply them during installation
> can't debian do a better job? i care more about ease of use than freeware philosophymany other distro just supply them
>
> these non-free firmware are same as software without source code??

But that's exactly why I love Debian: it doesn't hide those things
from me. I, as a user, get to make a decision every time Debian
installs a piece of non-free software on my box.

I really appreciate it this way, even if it is more work.

Cheers
- t
signature.asc

Andrei POPESCU

unread,
Jul 23, 2021, 6:40:05 AM7/23/21
to
On Vi, 23 iul 21, 17:11:25, loushan...@sina.com wrote:
>
> Thanks, as most adapters require firmware, it's not handy for user to
> supply them during installation
> can't debian do a better job? i care more about ease of use than
> freeware philosophymany other distro just supply them

https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/

> these non-free firmware are same as software without source code??

Yes, in Debian's opinion[1]. Other entities consider that these should
be treated specially, just because they don't run on the main processor
of the computer.

[1] In as much as the Debian Project can have an opinion, within the
project opinions vary as well.
signature.asc

Greg Wooledge

unread,
Jul 23, 2021, 7:20:05 AM7/23/21
to
On Fri, Jul 23, 2021 at 10:20:00AM +0300, Andrei POPESCU wrote:
> On the other hand, if the device would accept only firmware signed by
> the manufacturer the code itself could be open sourced.
>
> Users would still depend on the manufacturers to actually release
> updates, but at least they would have a way to contribute improvements
> to the code.

It would still fail any reasonable definition of "free software", though,
including Debian's DFSG. The user is not free to make any changes to
the software, not even for their own personal use. They're not even free
to rebuild the firmware and verify that it matches the official binary.
All they can do is look at the code and hope that the binary blob actually
matches it.

So, even in this hypothetical universe, the firmware would still be in
the non-free section.

Stefan Monnier

unread,
Jul 23, 2021, 12:20:04 PM7/23/21
to
> the tricky part of my search for ideal adapter(needn't non-free firmware)
> isthat many vendors claim they support linux, but i'm afraid they require
> non-free firmware
> is there some easy way to find out if it requires non-free firmware?

Buy it from a place that did this job for you.

E.g. my Librem mini came with a wifi adapter that doesn't require
non-free firmware, because the vendor went through the trouble (it
includes a bluetooth feature as well but that feature does require
a non-free blob, sadly).

I think you want to look for wifi adapters that work with the ath9k
driver (I don't know if that is sufficient to guarantee that they work
with a free firmware, tho).


Stefan

Andrei POPESCU

unread,
Jul 23, 2021, 1:10:05 PM7/23/21
to
On Vi, 23 iul 21, 07:17:31, Greg Wooledge wrote:
> On Fri, Jul 23, 2021 at 10:20:00AM +0300, Andrei POPESCU wrote:
> > On the other hand, if the device would accept only firmware signed by
> > the manufacturer the code itself could be open sourced.
> >
> > Users would still depend on the manufacturers to actually release
> > updates, but at least they would have a way to contribute improvements
> > to the code.
>
> It would still fail any reasonable definition of "free software", though,
> including Debian's DFSG. The user is not free to make any changes to
> the software, not even for their own personal use.

They could still submit patches.

> They're not even free
> to rebuild the firmware and verify that it matches the official binary.
> All they can do is look at the code and hope that the binary blob actually
> matches it.

Unless I'm missing something (which is very much possible, I'm way out
of my depth here) rebuilding to verify it matches the official binary
should still be possible.

Care to elaborate on why you think this would be a problem?

> So, even in this hypothetical universe, the firmware would still be in
> the non-free section.

Yes.

Still better than what we have now though ;)
signature.asc

Greg Wooledge

unread,
Jul 23, 2021, 1:20:04 PM7/23/21
to
On Fri, Jul 23, 2021 at 08:09:07PM +0300, Andrei POPESCU wrote:
> Unless I'm missing something (which is very much possible, I'm way out
> of my depth here) rebuilding to verify it matches the official binary
> should still be possible.
>
> Care to elaborate on why you think this would be a problem?

I suppose that if there is a way to chop up the binary blob into
"program" and "signature", then you could compare the two program
segments to each other, and ignore the signature segments. It would
depend on how this binary-blob-with-signature format is defined.

A simple cmp(1) of the two would clearly not work, as the signatures
wouldn't match.

But... even if the signature segments can be snipped off, it's possible
that there would be differences in the program segments, depending on
the compiler used, particularly optimizations. There could also be
timestamps, or pieces of the build environment such as directory paths,
embedded in the binary blob.

I'd have to defer to the "reproducible builds" people on that one. They
would have more experience with those kinds of issues.

Andrei POPESCU

unread,
Jul 23, 2021, 1:30:05 PM7/23/21
to
On Vi, 23 iul 21, 13:15:46, Greg Wooledge wrote:
> On Fri, Jul 23, 2021 at 08:09:07PM +0300, Andrei POPESCU wrote:
> > Unless I'm missing something (which is very much possible, I'm way out
> > of my depth here) rebuilding to verify it matches the official binary
> > should still be possible.
> >
> > Care to elaborate on why you think this would be a problem?
>
> I suppose that if there is a way to chop up the binary blob into
> "program" and "signature", then you could compare the two program
> segments to each other, and ignore the signature segments. It would
> depend on how this binary-blob-with-signature format is defined.
>
> A simple cmp(1) of the two would clearly not work, as the signatures
> wouldn't match.

Simply concatenating the signature with the binary is very simple,
there's not much technical reason to do anything fancier than that.

> But... even if the signature segments can be snipped off, it's possible
> that there would be differences in the program segments, depending on
> the compiler used, particularly optimizations. There could also be
> timestamps, or pieces of the build environment such as directory paths,
> embedded in the binary blob.
>
> I'd have to defer to the "reproducible builds" people on that one. They
> would have more experience with those kinds of issues.

Suport for reproducible builds has become the norm in the FLOSS world.
The potential issues and fixes / workarounds are pretty well understood
by now.
signature.asc

to...@tuxteam.de

unread,
Jul 23, 2021, 1:50:05 PM7/23/21
to
On Fri, Jul 23, 2021 at 08:09:07PM +0300, Andrei POPESCU wrote:

[...]

> > They're not even free
> > to rebuild the firmware and verify that it matches the official binary.
> > All they can do is look at the code and hope that the binary blob actually
> > matches it.
>
> Unless I'm missing something (which is very much possible, I'm way out
> of my depth here) rebuilding to verify it matches the official binary
> should still be possible.
>
> Care to elaborate on why you think this would be a problem?

You would have to have access at the vendor's build tools (compiler,
linker) and at the "build scripts", at least at enough of them to
be able to reproduce compile options, etc.

Depending on the "signature infrastructure" there might be other
"nice" challenges.

All in all, the vendor would have to be very cooperative.

Cheers
- t
signature.asc
0 new messages