carl9170

caveats

Firmware

Recovery

Users should be aware that these devices might go mad from time to time. Because these BUGs seem to occur too randomly to be identified, but happen often enough to be really annoying, the firmware and driver come with some convenient features to keep the overall downtime at a minimum and without requiring any user intervention. But as mention before there is a caveat: The user has to setup everything properly!

In general: The userspace has to be able to restore connectivity on its own as soon as the device reappears on the USB-Hub.

Multiple Interfaces

While the driver supports multiple virtual interfaces, in different combinations like:

just stations

just access points/mesh

access point / mesh (main interface) and stations (all slave) there are some important caveats: See FAQ for more details.

802.11n Compatibility

It's worth mentioning that the chip was designed, produced and sold in the early 802.11n-draft period. Compatibility will always be an issue.

A known problem is that hardware can not support frame aggregation and QoS at the same time, meaning the device is not suitable for any serious 802.11n setup. Also the hardware crypto has some serious trouble with encrypting/deciphering at high throughput, therefore if possible use 'nohwcrypt=1' as a workaround.

FAQ

General FAQ

Can I use newer carl9170 firmwares with any old carl9170 driver, or vice versa?

Depends on the combination. But the driver will evaluate, if it can safely support the firmware, or reject it.

Can I use the new carl9170 firmware with driver like otus or ar9170usb?

No.

Does the driver support the original firmwares?

No.

I don't need HT, how do I disable it?

Through a module parameter. 'noht=1'

How can I disable the hardware crypto?

Through a module parameter. 'nohwcrypt=1'

Recovery FAQ

I get “FW: … MAC RESET” kernel messages, what are those?

It's a tx/rx watchdog message. The hardware refused to process in-/outbound frames and the firmware tried to fix it. Even under normal conditions the message can be pop up from time to time.

How can I check if the recovery option works correctly?

You can easily test this by physically unplugging and replugging the device. If your connection is coming back, then you are done! If not, you have to find out how your distribution is doing network link hotplugging. All of a sudden, the device stops working for a few seconds (but recovers)

You should check if the driver has issued a device restart. There should be a “restart device (#number)” message in your system's logs.

#number

meaning

1

a fatal firmware error has occurred; the previous “FW” message contains more details

Multiple Interfaces FAQ

Why can't I enable more than two interfaces?

In order to overcome this limitation, you'll have to configure the firmware to provide more interface instances. But be advised that additional instances are not as free as you might think and you may lose some tx buffers.

I've setup a station and I can add more, so but why can't I have an AP now too?

Because you have to add and initialize the AP first.

How come my computer seems to be burdened with encrypting/decrypting?

This is expected, the hardware has problems selecting the right group-keys when multiple different keys are available. Because of this limitation, the driver disables crypto-offload and your CPU has to do it.

All of a sudden the device stopped transmitting?!

Maybe a different interface is scanning, or operating on a different channel. Note: All AR9170 only have ONE PHY, it isn't possible to operate on different channels at the same time!

Is it possible to mix Legacy, HT20, HT40+, HT40- channel settings?

No.

Is it possible to have different beacon period?

No, the beacon period must be the same, but you can have different dtim counts.

History

The Otus driver

Atheros merged support for their USB AR9170 2-stream 802.11n chipsets into the Linux kernel on the v2.6.29 release through a staging driver called Otus. The shortcomings for this driver was it required its own custom supplicant and obviously the code quality was sub-par.

ar9170usb driver

Shortly after Otus was submitted into staging Johannes Berg put a lot of effort into rewriting the driver for proper upstream inclusion. Christian Lamparter simply took what was already there, added a few finishing touches to addressed upstream considerations and we got it merged on the 2.6.30 release under the ar9170usb name.

During this time a lot of good work went into stabilizing the driver to replace the staging Otus driver from Atheros. The project had ambitious hopes to completely supersede the original Atheros staging driver: Otus.

To achieve this all functionality, performance, stability and quality must have been equally matched. In the end this proved quite challenging even though Atheros was kind enough to provide detailed documentations, hardware specifications and most importantly, they actually released the firmware source codear9170.fw under GPLv2!

It took months to dig through all the code and during this time the ar9170usb driver project lost most of its momentum and changes to the driver where limited to simple USB IDs updates, API fix-ups and serious crash fixes.

carl9170

Towards the beginning of 2010 a new shiny driver: carl9170usb started brewing with the main goal of replacing the existing driver and making use of only open firmware.

It took 1 year, 5 months, 9 days since this merge of ar9170usb upstream to release carl9170 with upstream inclusion intentions.

The carl9170 driver actually ends up not only replacing but superseding the staging Otus driver.