I switched to OpenWrt last year, and bought a PC Engines APU2 to run it on. It's been brilliant
So I finally got round to swapping the firmware on my old Netgear R7000 to OpenWrt (18.06.4) (I don't run WiFi from my router).
It was running Shibby's Tomato (for ARM) and the upgrade path I used took me via the stock firmware.
For each of these firmwares, the Internet LED worked and showed activity.
However, since being on OpenWrt, the Internet LED doesn't light at all
The LAN LEDs all work and flicker with activity, and the main Power LED shows colours and activity when booting, so the lights mostly work.
Each firmware change has had a factory reset (of course), and I've even tried loading the "kmod-ledtrig-netdev" module (as I needed a kmod LED module to get LEDs working on the APU2), but nothing has helped.
I've updated all packages, but this didn't help.
Is this a "known" issue? I've searched (the forum and afar), and haven't found anything mentioned.
Is there a configuration I need to do to get it working? Or just live with it not working?
Thanks!
Update: just to be clear, this is a cosmetic issue. The Internet WAN port gets a DHCP address fine, and traffic flows through it normally. It is purely the LED status light for the WAN port that isn't working.
@lleachii Thanks for the suggestion, but unfortunately the Internet WAN port LED is not one of the ones listed that can be assigned in the LuCI GUI
All of the LEDs except the WAN and LAN ports can be assigned to a function in the LuCI GUI.
So the best I can do is get the 2.4Ghz LED to operate as the WAN port LED, as it is the one next to it (and I am not attempting to use WiFi, even if it worked in OpenWRT).
My understanding is that the WAN and LAN ports are controlled automatically in the kernel (per supported model), but there may be a configuration file somewhere for it (just not in /etc/config/system).
Update: actually, this doesn't quite work
config led
option default '0'
option name 'Internet'
option trigger 'netdev'
option dev 'eth0.2'
option mode 'link tx rx'
option sysfs 'bcm53xx:white:2ghz'
It correctly flashes to show activity, but it doesn't ever go off: if I unplug the cable from the WAN port, it carries on flickering as if the cable were plugged in (i.e. I guess it sees the status of the WAN VLAN, but not the physical port?)
Likely, yes, as the switch is always connected to the MAC. Personally, I find activity (incoming, as outgoing will occur without a remote listener) more valuable than link-up.
config led
option default '0'
option name 'Internet'
option trigger 'netdev'
option sysfs 'bcm53xx:white:2ghz'
option dev 'eth0.2'
option mode 'rx'
so it only flashes on received/ingress traffic, then it is closer to what I want: if it goes quiet [no flashes] for too long, then I can assume there is an issue upstream.
I do still find it useful to know the status of the WAN link from the router, as I have mine routed through structured wiring to a remote cable modem, and one of the diagnostics steps [in my head] is always "is there an active link between the two units?". I know this can be found in different ways (through LuCI GUI, at the other end of the link, etc.), it is just a bit sad the actually LED doesn't work. A cosmetic issue for sure.
Perhaps I will have to fire up a Linux VM and look at the code
You should use Kong's latest builds of DD-WRT for the R7000, it's much better supported for that particular router, I used to have one and ran that firmware it was awesome. (now using a WRT32X on OpenWrt though.)
Apologies, my sentence should have ended with "visually".
I appreciate there are many different ways to find out through GUI or CLI, but a simple on/off LED is quicker (in my case).
I could run a cron job that checks the status of the WAN port and then alters the LED configuration manually to turn it on or off. I'll see if I can spot an issue in the code first though, just getting to grips with the build environment at the moment.
Well, I took the red pill and went down the rabbit hole that is the OpenWRT build system
Took a while to work out where the source code actually was, but then managed to get in to the kernel code, look at DTS files, and all sorts of fun 'n games
I could locate the definitions of the non-default LEDs, but that is no use to me
I believe the "default" LEDs (the LAN & WAN ports) are buried somewhere in the kernel code, and it is hard to pinpoint where.
I tried to use the util called "et" to probe the Broadcom chipset, but that is linked to /lib/ld-uClibc.so.0 which OpenWRT no longer supports (my understanding of using "ldd" to track the linkage, and reading around online).
Does anyone know a way of doing the functions that "et" provided but with current OpenWRT utils?
If I could probe around, I could try and activate the LED. If I can do that, then I can try to find out why it isn't activated by default in OpenWRT.
Not sure if that is going to work for you but I have LED switch flipped to Off. In order to monitor status of Internet connection I have put following line in /etc/rc.local:
(while true; do (sleep 2m; if ! (ping -c2 -q 1.1.1.1); then (downTime=$(date); echo "0" > /sys/class/leds/r7800:white:power/brightness; echo "1" > /sys/class/leds/r7800:amber:power/brightness; until (ping -c2 -q 1.1.1.1); do sleep 1m; done; (echo "0" > /sys/class/leds/r7800:amber:power/brightness; echo "1" > /sys/class/leds/r7800:white:power/brightness; echo -e "Subject: ${HOSTNAME} no Internet\n\nno Internet starting $downTime until $(date)" | sendmail $email; logger "WARNING: no Internet starting $downTime until $(date)"; unset downTime)); fi;) done;) &
Sendmail and logger part is optional. It also might make sense to replace 1.1.1.1 with the actual DNS server IP.
^ play around with those three file ( with your dts ) locations...
i think the key at least on my device... was the default wan state in DTS was FLIPPED so wan (connection) was ( mostly ) always UP... thus LED was mostly always off...
@anon50098793 Thanks for the info
Unfortunately, in the DTS file for my router (bcm4709-netgear-r7000.dts) neither the WAN LED nor the LAN LED are actually defined, so I can't edit anything I've checked through the "included" files, and it's not defined in a different DTS file either (that I could locate).
Hence I think it is being driven by the hardware driver deeper in the kernel, but that is just a guess at the moment.
not sure why two powers are defined... initial glance says maybe power amber > wan but from memory... there might be a WANLED in the switch... or something...
@anon50098793 yes, that is what I have. It doesn't have the WAN or LAN LED labels, just Power/5Ghz/2Ghz/WPS/Wireless/USB2/USB3.
So my understanding is because of this I can't control WAN or LAN LEDs by myself?
Update: the Power LED is multicoloured
the easier method is to just put stuff in /etc/config/system... but keep an eye out for that ACTIVEHIGH/LOW stuff...
So yeah... from memory/assumption... and i'm sure a good developer can correct me.... because there is no "WAN led" or it was oem controlled by the switch and not accessible when original pull's where made... ( and/or subtargets vary alot on this )...
Nothing was set in stone enough to be "core-acceptable".... thus users need to "choose-a-led" ( usb or power-amber ) to be the "wan-led".... ( edit: likely more of a mainline thing...? but still similar questions arise )
the "official" method was to add your board in 01_leds ... but I think the move was to port those to dts.. as these aren't managed in target/xyz... this might have created more ambiguity/blockages about what/when to do.
Something like that anyway... without going back to the pull requests.... i'm sure they explain it there
