What's a good Wireless PCI NIC for OpenBSD-5.8?

[hanzer]

Hi,

I have a poorly functioning Atheros AR9227 wireless PCI on FreeBSD 10.2 that doesn't work at all with OpenBSD. I'm tired of FreeBSD's "quirks" and administrative load so it's time to pony up and get a decent wireless network card that will work well with OpenBSD.

The firmware page and the FAQ page, 6.13 - What are my wireless networking options?, aren't really helping. Any suggestions on which chipset/driver is nicest and products on the market that are known to work well?

Thanks!

[shep]

At the moment OpenBSD does not support /n transmission speeds, just b/g. I have reliable connections with the ral(4) RT2561 and ath(4) based cards. The ral card requires firmware that the vendor agreed could be distributed by the project while the ath cards do not use firmware.

I've seen the older ral link cards for less than $10USD.

This is a good database with 3 search options. I usually look by chipset.

[hanzer]

Is there documentation, or an easy way to determine: which drivers are binary blobs from the manufacturer? It seems like some might be open-source with community development. (Does anyone know how/where the firmware files are generated?)

Suggestions for *really* good (and economical) products that make use of manufacturer binary blobs are welcome (well, by me).

[Oko]

Originally Posted by shep

At the moment OpenBSD does not support /n transmission speeds, just b/g

Who told you that nonsense? Man iwm on current.

[jggimi]

Originally Posted by hanzer

Is there documentation, or an easy way to determine: which drivers are binary blobs from the manufacturer?

On OpenBSD, none of the drivers are binary blobs. 100% of the drivers in chapter 4 of the OpenBSD manual are open source.

Firmware, on the other hand, is always supplied by the manufacturer. This is code that runs on the peripheral itself, and is not a driver, and does not run on the CPU.

There are three types of firmware:

• Included on the device itself, typically on ROM.
• Loaded into the device during initialization, by the (on OpenBSD, open source) device driver, from code which the manufacturers license for distribution with the OS.
• Loaded into the devices during initialization, by the driver, from code which the manufacturers do NOT license for distribution with the OS. These firmwares can only be installed after the OS has been installed, and use the fw_update(8) tool for installation and pkg_delete(8) for removal.

There is no list for the first type of firmware, but an example of this kind of device would be a hard drive. The drive electronics contains software which you cannot load, unload, or update.

The list for the second type of firmware can be found in /etc/firmware.

The list for the third type can be found on the firmware distribution server, http://firmware.openbsd.org. You will find some of these files on an OpenBSD machine in /etc/firmware, when installed by fw_update().

[jggimi]

And, as to blobs -- Binary, Large Object Blocks -- OpenBSD will never allow them in the OS, by policy. The Project even has a song about them.

[hanzer]

Originally Posted by jggimi

On OpenBSD, none of the drivers are binary blobs. 100% of the drivers in chapter 4 of the OpenBSD manual are open source.

Firmware, on the other hand, is always supplied by the manufacturer. This is code that runs on the peripheral itself, and is not a driver, and does not run on the CPU.

Hey jggimi,

Thanks for the clarification That's what I meant

[shep]

Who told you that nonsense? Man iwm on current.

I should have qualified that as being the case with the 5.8 release.

I also think iwm(4) based cards only are available for PCIe slots. The OP was looking for a PCI card.

[jggimi]

You're not the only one who might confuse firmware and blobs, Hanzer. There's a recent "fork" of OpenBSD which to me appears to be based entirely on this exact conflated misunderstanding.

[hanzer]

1. Is there documentation, or an easy way to determine: which firmware/chipset/manufacturer the driver developers recommend?

2. Which consumer products (based on 1) have OpenBSD users had success with?

[jggimi]

Firmware of type 1, 2 or 3 makes no difference whatsoever. All devices have one of these types of firmware.

When it comes to WiFi drivers and Wifi chipsets that work well (or do not) this is a constantly changing landscape. $ apropos wireless lists the currently available drivers, and each man page will describe any bugs or caveats you would need to be aware of.

You can see a history of recommendations from users (and sometimes developers) on the misc@ mailing list archives. About a decade ago I saw a presentation with a list of color coded recommendations, but I cannot locate it now and it would be well out of date. What was considered well supported or poorly integrated a decade ago is likely no longer useful information.

WiFi isn't the only type of device that might load a firmware file. In particular, Radeon video cards must lload firmware in order to control DRM signalling. You'll see Radeon firmware for download on that firmware server mentioned above.

[hanzer]

Originally Posted by jggimi

Firmware of type 1, 2 or 3 makes no difference whatsoever. All devices have one of these types of firmware.

It seems like the driver developers would see documentation from chipset manufacturers and have access to various products during driver development. I imagine they would do extensive testing with considerable instrumentation and metrics, too.

Originally Posted by jggimi

When it comes to WiFi drivers and Wifi chipsets that work well (or do not) this is a constantly changing landscape. $ apropos wireless lists the currently available drivers, and each man page will describe any bugs or caveats you would need to be aware of.

You can see a history of recommendations from users (and sometimes developers) on the misc@ mailing list archives. About a decade ago I saw a presentation with a list of color coded recommendations, but I cannot locate it now and it would be well out of date. What was considered well supported or poorly integrated a decade ago is likely no longer useful information.

WiFi isn't the only type of device that might load a firmware file. In particular, Radeon video cards must lload firmware in order to control DRM signalling. You'll see Radeon firmware for download on that firmware server mentioned above.

Holy crap! That's a lot of research. Do the driver developers share their documents and enough of their tools so that a third party could collect hardware and do serious evaluations of marketplace products? Something could be done like [an OpenBSD style of] Phoronix.

[jggimi]

Originally Posted by hanzer

It seems like the driver developers would see documentation from chipset manufacturers and have access to various products during driver development. I imagine they would do extensive testing with considerable instrumentation and metrics, too.

Access to interface documentation will produce the highest quality results, if the hardware happens to work as documented. But as you posted this in response to firmware comments; I'll repeat that it makes no difference to the quality of the driver or the quality of the hardware if that firmware is embedded in a ROM or loaded by the driver during initialization. It will be great or it will be terrible, or somewhere in between.

If documentation is not publicly available, then OpenBSD is less likely to have a useful device driver. The Project members will not accept a closed source driver, nor will any members sign an NDA for interface information in order to produce a driver. "Reverse Engineering" a hardware component is difficult, requires special skills, and usually produces an inferior program product.

...Do the driver developers share their documents and enough of their tools...

The documents? As stated, these would be vendor supplied, and from seeing presentations over the years I know that some vendors have never released any information, deeming it trade secret. Others have been very open, and that the quality and accuracy of the documents can vary. Tools? All guesswork on my part, as I am not a driver developer and know little of their needs. I will guess that the vast majority are the kernel and userland tools available in the OS. If network cable breakout boxes, radio beacon analyzers, or electronic header pinout tests tools are needed, then a developer would need to make those types of hardware investments. Do they? I don't know.

[hanzer]

Originally Posted by jggimi

Access to interface documentation will produce the highest quality results, if the hardware happens to work as documented.

It seems like driver developers would be in a position to assess the design quality of various products and how well each product performs in the OpenBSD environment, in comparison to the other products.

Do they share the insights, experience, and metrics they gather during driver development?

[jggimi]

Over the years, there have been both papers and presentations published. As I mentioned above. You can look through the list, if you like -- there are links to both in the sidebar of the main Project website.

Some examples of hardware discussion, from recent presentations at the presentation link. It goes back :to 1999, so there's a lot there. Just looking at recent hardware presentations:

http://quigon.bsws.de/papers/2015/as.../mgp00037.html
pages 12 and up from http://www.openbsd.org/papers/eurobs...eon_dsr500.pdf
http://www.openbsd.org/papers/eurobsdcon2014_iscsi/
http://www.openbsd.org/papers/eurobsdcon2013-mpath.pdf

[hanzer]

Originally Posted by shep

At the moment OpenBSD does not support /n transmission speeds, just b/g. I have reliable connections with the ral(4) RT2561 and ath(4) based cards. The ral card requires firmware that the vendor agreed could be distributed by the project while the ath cards do not use firmware.

I've seen the older ral link cards for less than $10USD.

Cool, how about a specific (vendor/product) card? I got burned with the AR9227 (chipset should work) in a TL-WN751ND (card does not work (with OpenBSD)).

Any there any recommendations for Intel cards?

Originally Posted by shep

This is a good database with 3 search options. I usually look by chipset.

Nifty, Thanks!

[shep]

Cool, how about a specific (vendor/product) card?

It is more the chipset.

SMC produced a PCI 54 card and versions 1 and 2 used the prism54 chipset. Prism54 chipsets are supported with native drivers. Later a Version 3 was released with an unsupported chipset. Also the rights to chipset were bought by Conexant who pull the firmware off the web. Only archived firmware for prism54 chipsets is available.

For the record, I'm using an Edimax EW-7128g which is also listed in ral(4). I googled and there are some available used in the $10-20 range and a "new" one in box for $24..

[hanzer]

Originally Posted by shep

SMC produced a PCI 54 card and versions 1 and 2 used the prism54 chipset. Prism54 chipsets are supported with native drivers.
[SNIP]...pull the firmware off the web. Only archived firmware for prism54 chipsets is available.

By "native drivers" do you mean that all of the software needed to use the NIC is in the OpenBSD distribution (i.e., on the installation CD)? So then versions 1 and 2 of the SMC produced a PCI 54 card with the prism54 chipset probably has a firmware license such that the OpenBSD project can distribute it, or the card might have embedded firmware (in flash memory, maybe).

[shep]

By "native drivers" do you mean that all of the software needed to use the NIC is in the OpenBSD distribution

Native meaning that the driver is specifically written for OpenBSD. In the early days of OpenSource wireless a wrapper script was developed that used windows drivers. It is still available in FreeBSD.

It would be an option for your AR9227 in FreeBSD.

[hanzer]

Originally Posted by shep

Native meaning that the driver is specifically written for OpenBSD. In the early days of OpenSource wireless a wrapper script was developed that used windows drivers. It is still available in FreeBSD.

It would be an option for your AR9227 in FreeBSD.

I am currently running FreeBSD on this machine and using the FreeBSD driver for the AR9227-based NIC. I have tried the Windows driver wrapper and posted my notes in this thread on FreeBSD-Forum. The problems I have with using the AR9227-based TL-WN751ND NIC under FreeBSD is also posted on DeamonForums in this thread.