Help for LED Configuration

Hi to all,
I installed openwrt on my tp-link tl-wr940n, everything works fine.
I only need to congurate wan led to be red when Internet connection is off and blue when connection is ok(like in OEM firmware). Is it possible?

Thank you very much


At least looking at the relevant DTS section of target/linux/ath79/dts/ar7240_tplink_tl-wr74xn-v1.dtsi, it appears that there is only a single GPIO associated with the "WAN" LED.

If you're willing to locate the proper GPIO for the alternate color and build your own firmware, it might be possible. Considering that it is subject to the, it's unlikely that this will "spontaneously appear" in a future version of OpenWrt.

Hi Jeff, thank you for your answer, what i would like to do is to turn on red light of there's no connection and Blue of there is, on the same led..i thought that this was possibile because with the stock firmware it happens.
I think to create a service(i don't know of service is the fight name) that pings Google DNS every 10 second, if get answer turn on Blue if not red..Is It possibile to work out this?

PS: i have no experience with Linux and customer firmware, i work in business intelligence😀

Ah, might be possible on the WR940N v4, based on target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr940n-v4.c which shows

  • tp-link:blue:wan
  • tp-link:red:wan

(This apparently did not get "pulled over" to the ath79 target)

This means that, if both those LEDs are available, you could turn "red" on and "blue" off when you don't have Internet connectivity, and vice-versa when you do.

It may be possible to do something through LuCI or /etc/config/system using the "netdev" trigger, though it doesn't look like it has access to the information you want to trigger on. It at least knows that the interface is up, or that traffic of some type is flowing, but not the high-level information around if packets are actually going to / coming from somewhere useful.

"Service" is probably the right name, once you get the script to do the test and manage the LEDs worked out. describes how to create your own, supervised service once you get to that point.

At a high level, what your script(s) need to do would be:

  • Initialize (once), for led in tp-link:blue:wan tp-link:red:wan (Edit: and/or set them up this way in /etc/config/system)
    • echo none > /sys/class/leds/${led}/trigger
    • echo 0 > /sys/class/leds/${led}/brightness
  • Running
    • test for connectivity
    • if "connected"
      • echo 0 > /sys/class/leds/tp-link:red:wan/brightness
      • echo 255 > /sys/class/leds/tp-link:blue:wan/brightness
    • else " not connected"
      • echo 255 > /sys/class/leds/tp-link:red:wan/brightness
      • echo 0 > /sys/class/leds/tp-link:blue:wan/brightness
    • sleep a while and repeat
1 Like

Thanks very much Jeff!!
Is there a way to debug stock firmware to understand which test Is used in It?

Unless there's a backdoor to get a shell, there isn't an easy way, nor would I consider TP-Link as providing a "good" way to do it either.

If I were to do it, my first check would be see if there is a public IP address assigned to the interface. I'd then probably ping the default gateway every few minutes, assuming that it answers pings. Something like

dgw=$( ip route get | cut -d ' ' -f 3 )
ping -q -c 1 -W 1 ${dgw} > /dev/null 2>&1 && echo "ok" || echo "FAIL"

(You'll need something a little more sophisticated, to cover if there is no default route and other unhappy-path conditions.)

Hi Jeff,on reddit I found this:

First you will have to figure out which LED to use in /sys/class/leds/... Make sure in advanced setting you set that led to [none] so that nothing activates it.

My script for Internet monitoring: #!/bin/sh

while [ true ]; do
	/usr/bin/wget -q -s > /dev/null
	if [[ $? -eq 0 ]]; then
	        echo "255" > /sys/devices/platform/leds-gpio/leds/gl_ar150:lan/brightness
	        echo "0" > /sys/devices/platform/leds-gpio/leds/gl_ar150:lan/brightness
	sleep 10

and created a init.d script to start it at boot:

#!/bin/sh /etc/rc.common


	/usr/bin/wifiLED &

	killall -9 wifiLED

And you'll have to enable that with /etc/init.d/<your script> enable and /etc/init.d/<your script> enabled

Do you think I can use it?

wget is a resource expensive way to test your internet connection, especially if done every 10 seconds.

Can you tell me another way?

i would prefer to just use one led for TX and the other for RX and just trigger them when link is ON or blink when activity on RX or TX.


But if you want hard test this would be better than wget

Hi to all,
finally I got my scripts:

#!/bin/sh /etc/rc.common
#controllo internet
while :
    Stato=$(ping -q -c 1 -W 1  > /dev/null 2>&1 && echo "ok" || echo "FAIL")
	if [ "$Stato" = "ok" ]; then

    echo 0 > /sys/class/leds/tp-link:red:wan/brightness
    echo 255 > /sys/class/leds/tp-link:blue:wan/brightness


    echo 255 > /sys/class/leds/tp-link:red:wan/brightness
    echo 0 > /sys/class/leds/tp-link:blue:wan/brightness

	sleep 10

everything works fine. Now i would like to add another check:
if the wan port is unplugged led should be off. I know there is trigger netdev and trigger-option:link, but i don't now how to "catch" it.
My script should become:

if("cable not plugged to wan") then
     echo 0 > /sys/class/leds/tp-link:red:wan/brightness
     echo 0 > /sys/class/leds/tp-link:red:wan/brightness
      ....the actual scripts

is it possible?
thank you very much

1 Like

You can usually trigger on traffic in/out of an interface with the built-in LED trigger system.

To detect cable plugged (and something live on the other end, since it's done electrically, not mechanically), one way is with looking at the switch data. For example, from an Archer C7 v2

jeff@office:~$ swconfig dev switch0 show | fgrep link
	link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
	link: port:1 link:up speed:1000baseT full-duplex auto
	link: port:2 link:down
	link: port:3 link:down
	link: port:4 link:down
	link: port:5 link:down
	link: port:6 link:up speed:1000baseT full-duplex txflow rxflow 

(Ports 0 & 6 are, as I recall, those attached to the SoC)