Control the LED on a USB WiFi Adapter on Linux

Last updated on October 11, 2018

First, find the corresponding directory of this LED device in /sys/class/leds, such as /sys/class/leds/device_name, and switch your working directory to this directory. The device_name may be similar to the device driver of your wifi adapter. You should have a file named trigger and a file named brightness in this directory. cat trigger shows you available triggers to trigger the LED light, with the current trigger surrounded by brackets. Different triggers will turn on and off the LED in different cases. Use echo new-trigger > trigger to change trigger. cat brightness shows the current brightness of the LED. Use echo N > brightness to change brightness, where N is an integer.

For example, I have a USB wifi adapter with an Atheros AR9271 chip, which is powered by the driver ath9k_htc on Linux. When I plug in the device, I have a new directory /sys/class/leds/ath9k_htc-phy0 created on my system. cat trigger outputs

none cpu0 cpu1 cpu2 cpu3 usb-gadget usb-host rfkill0 phy0rx phy0tx phy0assoc phy0radio [phy0tpt]

The default, phy0tpt, causes the LED to blink when there are activities. echo phy0radio > trigger causes the LED light to be on when this wifi interface is on. echo phy0assoc > trigger causes the LED to be on when connected to an access point. You can check the relevant document for explanation of phy0rx, phy0tx, phy0assoc, phy0radio, phy0tpt (Check the corresponding functions to see what these triggers mean). echo none > trigger means no trigger. That is, LED will be controlled manually. In this case, echo 255 > brightness can be used to turn on the LED, and echo 0 >brightness to turn it off.

If you want to automatically use a different trigger other than the default trigger when the adapter is plugged in, you can make a udev rule to do this. Note that this link is about flash drive, but the rule is the same for any USB devices. In my example I above, I created a script wifi-led.sh to update the trigger:

#!/bin/bash

for trigger in /sys/class/leds/ath9k_htc-phy*/trigger; do
    id=$(echo $trigger | sed -e 's/.*ath9k_htc-phy\([0-9]\).*/\1/g')
    echo "phy${id}radio" > $trigger
done

And add a new udev rule 100-usbwifi.rules to /etc/udev/rules.d to run this script when the adapter is plugged:

ACTION=="add", ATTRS{idVendor}=="venid", ATTRS{idProduct}=="prodid", RUN+="/path/to/wifi-led.sh"

Replace venid and prodid with your actually usb device ID. You can see the ID by running lsusb. For example, I have this following line output by lsusb corresponding to my USB wifi adapter.

Bus 001 Device 004: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n

where 0cf3 is the vendor ID, 9271 is the product ID.

7 thoughts on “Control the LED on a USB WiFi Adapter on Linux

  1. Robert Schaffrath

    I wish the MT7601U had this capability or a driver option to turn the LED off. At night, the tiny dongle can practically light up a room with it’s bright blue LED. There is no file in /sys/class/leds for the MT7601U but I do manipulate other LED’s on the system through the trigger file at startup with an @reboot directive in the root crontab.

    The developers of the RTL8188EU driver did add an option to the driver’s modprobe configuration in /etc/modprobe.d to turn the LED off on those devices (rtw_led_enable=0) but they have such dim LED’s (mine anyhow) that I do not need to use it.

    Reply
  2. Pingback: GNU/Linux Qualcomm Atheros AR242x AR542x ath5k wireless driver issues | OSDE

  3. jpp

    Hi, work perfectly.
    but something I do not understand, your script create a “ls” file in the current dir. Do you know why ?

    Reply
    1. jpp

      well, I should have found it, sometime it is in front of your eyes
      for .. in … doesn’t need ls at all !! you can remove ls in your script

      Reply
      1. Hong Post author

        Thank you, I’ve already removed it now. There used to be backsticks quoting them, but somehow they became missing when I moved to WordPress…

        Reply
  4. pbhj

    FWIW your html encoded “>” are not getting written correctly to the page and are appearing as “>”.

    Thanks for the info though, this worked for me when attempting to set “blink” off using a .conf file in modprobe.d didn’t. Surprisingly this has largely fixed, it seems, a major ping-lag issue.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *