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?
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 https://openwrt.org/supported_devices/432_warning, 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. https://openwrt.org/docs/guide-developer/procd-init-scripts 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)
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
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 http://google.com > /dev/null
if [[ $? -eq 0 ]]; then
echo "255" > /sys/devices/platform/leds-gpio/leds/gl_ar150:lan/brightness
else
echo "0" > /sys/devices/platform/leds-gpio/leds/gl_ar150:lan/brightness
fi
sleep 10
done
#!/bin/sh /etc/rc.common
#controllo internet
while :
do
Stato=$(ping -q -c 1 -W 1 8.8.8.8 > /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
else
echo 255 > /sys/class/leds/tp-link:red:wan/brightness
echo 0 > /sys/class/leds/tp-link:blue:wan/brightness
fi
sleep 10
done
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
else
....the actual scripts
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)