Atheros USB (Driver: "ath9k_htc&q...

  • Vadim Plessky

    Vadim Plessky - 2010-10-10


    I'd like to know if it's possible to add support for Atheros USB ("ath9k_htc") Wireless adapter to NST 2.13.0?

    Adapter I have is TP-Link TL-WN722N

    Vendor: usb 0x0cf3 "Atheros Communications, Inc."
      Device: usb 0x9271 "USB2.0 WLAN"
      Revision: "1.08"
      Serial ID: "12345"
      Driver: "ath9k_hif_usb"
      Driver Modules: "ath9k_htc"

    This adapter is supported in Fedora 14 Beta, and in OpenSUSE 11.4 branch.
    NST 2.13.0 doesn't recognize it.

    Reason why I am intersted in this particular Wi-Fi USB stick - it has external detachable antenna.
    Standard antenna 4dBi, and I can get very good signal from all Access Points around, much better than standard built-in Wi-Fi or typical USB Wi-Fi stick without antenna.

  • Paul Blankenbaker

    The detachable antenna sounds like a nice feature. I've poked around a bit, but have not come across a easy solution to build the driver. Ideally, I would suggest:

    1. Install the kernel-devel and kernel-headers package
    2. Locate the source code for the for the ath9k_htc and ath9k_hif_usb modules
    3. Extract the source and run ./configure; make; make install

    That's my typical approach at adding drivers for specific hardware to the kernel. Unfortunately, after a bit of googling I was unable to locate the source code as a tar.gz file for the modules your hardware requires.

    You said that the Fedora 14 Beta kernel supported you Wi-Fi USB stick. Are the modules owned by the kernel package? It might be a long shot due to dependency issues, but you could try downloading the Fedora 14 Beta kernel RPM and installing it on a NST system (I would recommend trying it on a Live boot first). There are probably dependency issues, but it might be worth a shot.

    Interestingly enough, it looks like the firmware /lib/firmware/ar9271.fw is available for Fedora 13 (I see it on my installation).

    Good Luck,

  • Vadim Plessky

    Vadim Plessky - 2010-10-11

    This adapter is supported by both OpenSUSE 11.4 branch and Fedora 14.
    I tested it by plugging-in USB adapter after booting using LiveCD.

    I have filed some time ago bug report against OpenSUSE 11.3 - see
    But code maintainer responded that backporting from 11.4 to 11.3 is impossible, "due to intrusive changes".
    So I think pulling kernel from Fedora 14 would not help/work.

    This Wi-Fi USB adapter is also listed here:

    Vendor          Product         Chipset         USB vendor      Product

    TP-Link      TL-WN721N      AR9271      0x0cf3      0x9271
    TP-Link     TL-WN722N     AR9271             0x0cf3      0x9271

    Full list of devices using same chipset:
    (from Linux-Wireless)

    TP-Link     TL-WN721N   AR9271      0x0cf3      0x9271      500mA
    TP-Link     TL-WN722N   AR9271  0x0cf3  0x9271  
    TP-Link     TL-WN422G v2    AR9271  0x0cf3  0x1006  
    Atheros         AR7010  0x0cf3  0x7010  
    Atheros         AR9271  0x0cf3  0x7015  
    Netgear     WNA1100     AR9271  0x0846  0x9030  
    Netgear     WNDA3200    AR9271  0x0846  0x9018  
    D-Link  150     AR9271  0x07d1  0x3a10  
    Azurewave       AR9271  0x13d3  0x3327  
    Azurewave       AR9271  0x13d3  0x3328  
    LiteOn      AR9271  0x04ca  0x4605  
    SMC Networks        AR9271  0x083a  0xa704

    Do you plan release of NST based on Fedora 14 in nearest future?
    I know that you just did fresh release week ago.
    But Fedora 14 would be out in a month.
    So upgrading to it or NST based on F14 would be attractive.

  • Paul Blankenbaker

    At this point, we do not plan on having a Fedora 14 release. Fedora moves to a new release about every six months. It takes a considerable amount of effort for us to produce a release. We just don't have the resources to produce a release of the NST every six months. So, our current plan is to keep working on the NST v2.13.0 packages and to make them available to everyone via yum updates. We probably won't move to a new version of Fedora until Fedora 15 is released.

    Hopefully you will find another way to compile the modules or build a kernel for your Wi-Fi chip set. Maybe you will get lucky and a update to the Fedora 13 kernel will be released containing the necessary modules.

  • Paul Blankenbaker

    There is another possible thing that's relatively easy to try. Try enabling the "rawhide" repository (Fedora's test packages) and then try updating your kernel (you may want to experiment on a live boot before updating a hard disk install):

    yum install nst-release-rawhide
    yum --enablerepo=rawhide update kernel

    The current test kernel does include the "ath9k_htc.ko" module. Not sure if that's enough to get your card working, but it's something you can try.


  • Vadim Plessky

    Vadim Plessky - 2010-10-12

    Do you use standard Fedora 13 kernel in NST v2.13?
    Or to put this in different way - does standard Fedora 13 kernel support packet injection?

    In my test of Fedora 14 Beta - I get injection test like described at working, but real injection doesn't work.

    Besides, airodump was monitoring traffic on "channel -1" while being asked to use channel 11.
    I got response on that this is known bug and it has been fixed (with reference to patch dated June 2010).
    But it seems that patch was not included into Fedora 14 Beta.

  • Paul Blankenbaker

    We distribute the NST using the stock Fedora 13 kernel. To determine whether the stock kernel supports packet injection with a Wi-Fi card, I thought the command was as follows:

    [root@cayenne-e ~]# aireplay-ng --test wlan0
    08:36:34  Trying broadcast probe requests...
    08:36:34  Injection is working!
    08:36:35  Found 1 AP 
    08:36:35  Trying directed probe requests...
    08:36:35  00:26:5A:B4:17:49 - channel: 1 - 'redali'
    08:36:37  Ping (min/avg/max): 5.562ms/60.786ms/122.288ms Power: -38.27
    08:36:37  30/30: 100%
    [root@cayenne-e ~]#

    However, I'm assuming that this depends upon the level of support compiled into the wireless driver and may vary based on the hardware/driver combination.

    I'm not familiar with Fedora 14 beta or the Intel 5100 chipset.

  • Vadim Plessky

    Vadim Plessky - 2010-10-12

    Simple injection test - according to

    #aireplay-ng -9 wlan0

    Mode advanced test - card-to-card injection.
    Assuming you have two wireless adapters, one monitoring on mon0 and second on mon1.

    aireplay-ng -9 -i mon1 mon0

    -i mon1 mimics Access Point.

    Real injection test - from

    Step 4 - Use aireplay-ng to do a fake authentication with the access point

    #aireplay-ng -1 0 -e <AP SSID> -a <Access Point Mac address>  -h <client Mac address> mon0

    Step 5 - Start aireplay-ng in ARP request replay mode

    #aireplay-ng -3 -b <Access Point Mac address -h <client Mac address> mon0

    Just note that I replaced ath0 with mon0.
    This is working with several wireless adapters I have - built-in Ralink RT2500, Atheros AR9170USB, Ralink RT73USB.
    To my surprise, it also worked in certain configurations with Intel 5100 ('iwlagn' driver)

    Problem with Atheros ('ath9k_htc' driver) in Fedora 14 Beat is that ARP request replay mode doesn't work.
    ARP packets are not injected, and therefor number of IVs was not increasing.
    Problem with the same adapter in Fedora 13 or NST v2.13 - that it is not supported.

  • Vadim Plessky

    Vadim Plessky - 2010-10-12

    I uploaded several screenshots to my Flickr page,  showing what you should get to ensure packets are injected - and you can find required key.

    Router / Access Point setup - 802.11g, 54Mbps, WEP

    Pentoo Linux - see ARP package generation in the right window

    Whatever adapter I used, packets are always injected with speed about 500pps.

  • Paul Blankenbaker

    Thanks for the detailed information and screen shots. My spare Wi-Fi access point is on loan to my mother in law at the moment, but when I get it back, I may configure it for WEP and try the experiment you show above to see how quickly the WEP key is found using packet injection.

    Are there other good reasons to use packet injection other than demonstrating weaknesses in WEP? My general rule of thumb is never to use WEP (I just take it for granted that WEP should not be used).

  • Vadim Plessky

    Vadim Plessky - 2010-10-13

    I guess we are still far away from situation when everyone is aware about WEP weakness and uses WPA or WPA2.
    Besides, there are some specific configurations when you have no choice but WEP.
    In particular - Wireless Bridge configuration, or WDS works only with WEP, and doesn't work with WPA (on some branded hardware, don't want to mention its name here)
    So if someone needs a wireless bridge, and needs it fast - they would deploy it using WEP, with all consequences out of this.
    May be they would tunnel traffic using VPN, but for people who want to hijack and just use someone else's connection it's still fine.

    About packet injection/network monitoring.
    For me network monitoring is more important.
    I had situations when my computer doesn't want to connect via Wi-Fi to my Access Point.
    That was when I had test with two concrete walls between AP and computer, and weak wireless adapter (RT2500 on old notebook)
    I was really confused, as in one room everything worked ok, and connection was hanging when I am at my kitchen.
    With wireless network monitoring you can see what's going on.
    Most likely, some packets were lost or coming damaged to wireless client.

    Injection is also useful to observe behavior in stress situation and sustainability of your network.
    When you have some sequence recorded, you can replay it (using aireplay) required number of times, or using different adapters.  And see how network/AP behaves.
    So obviously you should have injection working, and working reasonably well.

    Regarding speed of packet injection - it's really not most important, at least for me.
    Again it is good to have possibility to inject packets fast for stress testing.
    But you can also achieve this by using 2nd wireless adapter, working on mon1.
    I have not tested it, but this should work.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks