Netgear R7000 - No Internet LED status

I switched to OpenWrt last year, and bought a PC Engines APU2 to run it on. It's been brilliant :smile:
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 :frowning:
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?


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.

@Lewpy, welcome to the community!

  • In the web GUI, browse to System > LED Configuration
  • Configure LEDs as desired

@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 :frowning:
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.

@jeff yes, if I change it to

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 :nerd_face:

1 Like

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.)

Kong no longer builds DD-WRT, but OpenWrt now, from what I understand. There is a thread here about his OpenWrt builds.

1 Like
swconfig dev switch0 show

and your choice of grep to pull what you want.

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.

1 Like

Well, I took the red pill and went down the rabbit hole that is the OpenWRT build system :anguished:
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 :grinning:
I could locate the definitions of the non-default LEDs, but that is no use to me :frowning:
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/ 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.

Moved to For Developers section as getting down into low-level questions.


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; 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; 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 with the actual DNS server IP.


I run a c5v2... and had to make some changes here... here are some of my ( imperfect ) notes..... ;

+config led
+	option name 'wanon'
+	option sysfs 'bcm53xx:green:wan'
+	option default '1'
+	option trigger 'netdev'
+	option dev 'eth0.2'
+	option mode 'tx'
+config led
+	option name 'wanoff'
+	option sysfs 'bcm53xx:amber:wan'
+	option trigger 'netdev'
+	option dev 'eth0.2'
+	option mode 'link'
+	option default '1'

+++ b/build_dir/target-arm_cortex-a9_musl_eabi/linux-bcm53xx/linux-4.14.131/arch/arm/boot/dts/bcm47081-tplink-archer-c5-v2.dts
@@ -57,7 +55,7 @@
 		wan-amber {
 			label = "bcm53xx:amber:wan";
-			gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
+			gpios = <&chipcommon 8 GPIO_ACTIVE_LOW>;


^ 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...

1 Like

@anon50098793 Thanks for the info :slight_smile:
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 :frowning: 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.

what source release are you working with?

master has;

	leds {
		compatible = "gpio-leds";

		power-white {
			label = "bcm53xx:white:power";
			gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
			linux,default-trigger = "default-on";
		power-amber {
			label = "bcm53xx:amber:power";
			gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
		5ghz {
			label = "bcm53xx:white:5ghz";
			gpios = <&chipcommon 12 GPIO_ACTIVE_LOW>;
		2ghz {
			label = "bcm53xx:white:2ghz";
			gpios = <&chipcommon 13 GPIO_ACTIVE_LOW>;
		wps {
			label = "bcm53xx:white:wps";
			gpios = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
		wireless {
			label = "bcm53xx:white:wireless";
			gpios = <&chipcommon 15 GPIO_ACTIVE_HIGH>;
		usb3 {
			label = "bcm53xx:white:usb3";
			gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
		usb2 {
			label = "bcm53xx:white:usb2";
			gpios = <&chipcommon 18 GPIO_ACTIVE_LOW>;

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...

1 Like

@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 :slight_smile:

1 Like

well the 01_leds only handles r8000 for that target...

as the dts only defines behavior for power ( white )...


probably with a netdev see...;

fgrep -r 'netdev' target/linux/*/base-files/etc/board.d/01_leds

for samples

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 :slight_smile:

1 Like