carl9170 is the 802.11 draft-n USB driver with GPLv2 firmware for Atheros USB AR9170 devices.

Before you can use the driver, you have to get the the right firmware.

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.

See FAQ for more details.

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.

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.

See Contact, if you want to report issues with specific setups.

• 802.11abg/bg + draft-n (depending on hardware)
• 1 or 2 spatial streams for 802.11 draft-n (depending on hardware)
• GPLv2 firmware
• Up to 9 (1 Master, 8 Slave) Interfaces
• programmable LEDs
• WPS Button (depending on hardware)

• legacy (802.11abg) access point, mesh, p2p (go and client), ad-hoc operation mode
• 802.11 a/b/g/draft-n station mode, monitor (with injection)
• cryptographic accelerator when operating as a single station, or single access point.
• Multiple interfaces
• full support for MRR (minstrel & minstrel_ht) rate control algorithms
• Input device for WPS button event (depending on hardware)
• automatic recovery from several fatal events
• Regulatory domain restrictions
• channel utilization report
• Protected Management Frames (802.11w)
• TDLS

• Power Save Mode, It's implemented but buggy
• Wake-on-LAN support (can resume your system from suspend-to-ram)
• SMPS
• long-distance links
• Hardware WMM
• RIFS

• Accelerator for CCX (Cisco)
• real 802.11n AP
• Radar detection

The latest version is available from wireless-testing.git.

There is code available, check out the carl9170.fw page for more details.

The firmware can be obtained from firmware tree.

Alternately you can download the GPLv2 Firmware binary from here (rename to carl9170-1.fw):

• 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'

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.

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

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.

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 code ar9170.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.

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.

• no special mailing list, use the linux wireless list for development and firmware issues