Posted: Mon Nov 11, 2019 4:13 Post subject: 'et robowr' Ethernet LED commands for R7xxx* don't work.
Hi all,
TL;DR: If you have an R7000 running a year-old+ build of DD-WRT (or Tomato, or AsusWRT-Merlin, or ...), or you really want to control the LEDs on your R7xxx and you don't mind flashing (potentially many) *very* old firmware revisions, you might like to try the commands listed at the end of this post that do not work on current DD-WRT firmware for reasons currently unknown.
Recently started using^Wtinkering around with an R7000. It's not a bad bit of kit
Partly out of curiosity and partly because (to be honest) I wanted a "cool" solution to the problem of the (very bright) LEDs shining on my ceiling and making it a tad difficult to get to sleep I wanted to figure out how to reproduce the Genie behavior where you can turn most of the LEDs off.
Unfortunately this does not seem to be possible. I've wandered around the internet for a couple days and tried many different variations of 'gpio', 'et' and 'wl' commands. None of the 'et robowr' commands I have found will get all of the Ethernet LEDs switched off.
Reading https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1131616 ("Turn off all LEDs on Netgear R7000P"), it would seem that this may be due to DD-WRT changes from potentially at least a year (or more) ago (that thread spanned from June to Nov 2018).
In my own case, my R7000 (running 40559) behaves exactly as described at the end of the above linked thread - the best I can seem to manage is to get the LED for Port 1 steady on, with the other three port LEDs steady off.
So, I'm making this post to add some confirmational anecdata and document what I've tried and discovered in case it is useful to others, because I can't/don't want to go any further - (IIUC), CFE can't boot from the USB ports or upload directly into RAM, and I don't want to wear my flash out: I value my R7000's ability to be a router more than its ability to be a controllable Christmas tree and I don't know how many revisions I'd need to flash to properly bisect this (I'd assume tens to low hundreds, as I have no scoping hints).
---
The front panel LEDs are connected in two different ways. Most use GPIO, but the Ethernet port LEDs run directly to dedicated I/O lines on the switch controller ASIC where they are efficiently blinked from hardware.
It's really easy to play with the GPIO-connected LEDs. I did the trial and error to trace each GPIO (and in the process learned that gpio enable 6 (or it might be "disable") causes a factory reset (and who knows what else))... but I'll defer to the list over at https://www.linksysinfo.org/index.php?threads/netgear-r7000-tomato-shibby-stealthmode.73034/ which is already nicely written up and corroborates all my findings.
But I simply went around in circles with the info on the 'net referencing the et robowr commands for the Ethernet LEDs. After getting tired of this I decided to see if giving the Genie firmware a good shake would make any clues fall out (and whether I'd notice/be able to decipher them, lol).
With the .chk file (and the squashfs filesystem it contains) chewed up and spat out very efficiently by binwalk, I had a look around, and... wow, Genie is quite the mess: no high-level languages used, just lots of C binaries shelling out to yet more C binaries. The sad status quo of consumer hardware, I guess.
But the obsession with system() has a silver lining: a simple grep is all that is needed to find et robowr command references in /usr/lib/libacos_shared.so with parameters identical to the ones posted online in connection with LED control.
Except strings left the output somewhat inscrutable, and trying the et commands I'd found didn't seem to do anything anyway, so I decided to try my luck at following ARM disassembly, and fired up IDA.
Ha, no real reverse-engineering was needed: the et robowr strings are straightforwardly referenced by a set_led_settings() function, whose behavior was extremely obvious: there are three flows, one for each mode (LEDs flashing, LEDs steady, all LEDs (except Power) off).
A quick grep for "set_led_settings" (since this is an exported symbol, and will exist as a literal in the binary images that call it) finds references in /usr/sbin/httpd; IDA reveals that httpd calls set_led_settings() with an integer value when the browser POSTs "en_blink", "dis_blink" or "turn_off" back from user choices at /www/LED_settings.htm. My IDA version doesn't have an ARM decompiler, and I'm... assembly-challenged , so I THINK that httpd maps "en_blink" to 1, "dis_blink" to 2, and "turn_off" to 3.
I've attached disassembly screenshots of libacos_shared.so and httpd, for canonical reference, and so you can peer-review my guestimation regarding the mapping.
I might've gotten the enable/disable blocks round the wrong way, but here are the et robowr commands the Genie firmware runs to adjust the LEDs. There are a few tidbits in here that I've not found on the internet anywhere
Turn off:
Code:
et robowr 0x0 0x18 0x0
et robowr 0x0 0x1a 0x0
Enable blinking:
Code:
et robowr 0x0 0x18 0x1ff
et robowr 0x0 0x1a 0x1ff
et robowr 0x0 0x10 0x0301
et robowr 0x0 0x12 0x022
Disable blinking:
Code:
et robowr 0x0 0x18 0x1ff
et robowr 0x0 0x1a 0x1ff
et robowr 0x0 0x10 0x3000
et robowr 0x0 0x12 0x0078
However,these commands don't work for me, and may not work for you either,but they might ifyour DD-WRT version is *at least* a year old.There is yet no known/logical reason as to why.
Hence why I'm dumping this here.
On the one hand, these are the exact commands being run by the LATEST version of Genie (currently R7000-V1.0.9.88_10.2.88).
On the other hand, that latest version is based on Linux kernel version "2.6.36.4brcmarm+ (builder@production) (gcc version 4.5.3 (Buildroot 2012.02) ) #30 SMP PREEMPT Thu Jun 20 16:25:36 CST 2019"!
(binwalk extracted a 5MB file bizarrely named "56" from the .chk; running binwalk again on that "56" file found the above signature.)
My R7000's happily humming away with kernel 4.4.187 right now and while that's awesome, 2.6.36.4 to 4.4.187 is a rather large entropy pool of difference for *something* to have changed out from underneath whatever it is these commands are blindly poking. My guess is that some driver is initializing/configuring hardware subtly differently.
So: What was DD-WRT running a year ago? Kernel 3.0? Was it just about to leave 2.6? (I don't know, and I am disinclined to find out since I don't want to reflash my router more frequently than every few weeks/months.) IMHO, these types of questions are probably a good starting point for anyone looking for answers.
If you really, really want to get LED support working, and you accept the risks that come with repeated reflashing (and trying random DD-WRT versions), start with an old DD-WRT build from, say, early 2018 - or maybe mid 2017? - and see if the above commands work. If they don't, keep winding backwards (maybe by intervals of 3-6 months) until you have LED control, then iterate back and forth with progressively smaller jumps to find the exact point where one revision works but the next revision doesn't. Then post here - I wish you the best of luck in not bricking your router, and that you succeed before your flash wears out. (Maybe also go back to Genie briefly, to get proof positive that you can indeed control the LEDs on your R7xxxx*.)
The info you post may result in anything from immediate restoration of functionality , to regrouping and working out next steps. For example if you discover that LED control broke at the switch from 2.6 to 3.0, or 3.0 to 4.0, or something major like that, someone with significant experience (and conversely limited time ) would likely need to take a look at the situation.
---
One last thing that doesn't really explain much and is of zero practicality but which might be cute/interesting to others:
If I run this on my R7000 w/ 40559, all four Ethernet LEDs will begin to flash VERY rapidly (a reboot may be needed if this doesn't work, particularly after playing with the above commands):
Code:
et robowr 0x0 0x18 0x0
They'll be flashing "pink".
But once I run this:
Code:
et robowr 0x0 0x10 0x3000
The red diodes will switch off, and the flashing will be pure white.
This proves the 0x10 0x3000 sequence does have an effect of some kind.
Rebooting the router gets it back to normal. (Various other robowr commands could switch the LEDs off, but you'd presumably want the LEDs to to go back to how they were before.)
If trying the above (preferably after a reboot) produces anything else, that may be interesting to report.
libacos_set_led_settings.png
Description:
Filesize:
145.83 KB
Viewed:
11428 Time(s)
httpd_set_led_settings.png
Description:
Filesize:
77.35 KB
Viewed:
11427 Time(s)
Last edited by i336_ on Mon Nov 11, 2019 4:25; edited 1 time in total
One other thing I noticed, which I'm putting in a separate post due to the two-attachment limit: leddown and ledup.
These are symlinks to /sbin/acos_service, which appears to be a busybox-inspired binary that does different things based on the symlink used to call it.
I don't know the significance of these commands (ie I haven't traced leddown/ledup backwards in the firmware), because they only contain yet more et robowr commands that also don't work for me. I am naturally of limited motivation to try and follow this up - adding for completeness.
leddown calls:
Code:
et robowr 0x0 0x18 0x0
et robowr 0x0 0x1a 0x0
ledup calls:
Code:
et robowr 0x0 0x18 0x1ff
et robowr 0x0 0x1a 0x0
The screenshots of the respective disassembly is attached.
I don't know why ledup calls et robowr differently to the commands posted above.
Hypothesis: perhaps the code in libacos_service.so is used on the R7000, while this code is used on other router models. No idea.
Or maybe that's totally invalid, and these calls control the LEDs during bootup.
leddown.png
Description:
Filesize:
37.99 KB
Viewed:
11426 Time(s)
ledup.png
Description:
Filesize:
38.36 KB
Viewed:
11426 Time(s)
Last edited by i336_ on Mon Nov 11, 2019 4:27; edited 1 time in total
Finally, documenting a last ditch "maybe" I also tried, I chrooted into the Genie firmware just in case its et command was different. No dice. strace shows it behaves identically to the et version I'm using.
...Which actually brings me to a bit of a case in point - my DD-WRT build doesn't have et! I don't understand the rationale behind not including it. It appears to be part of the "rc" distribution, and a component worth including by default...? It's only 17KB...
So, attached to this post is the et binary extracted from dd-wrt.K3_R7000_6.chk. It runs just fine in the DD-WRT build I'm using (the most straightforward way to get it onto the router is to enable scp; barring that, stand up a web server and use wget). Of course, it's certainly arguable that "I'm doing something incorrectly" because I'm using an et binary from a different DD-WRT build, but since my R7000's LEDs are broken in exactly the same way others' are, I'm dropping "maybe it's my et binary" down a couple of notches on the "likely importance" chart.
(It's packed as a .zip file so the forum would accept it. I picked .zip over .tar.gz for easier manipulation on Windows et al. Don't forget to chmod +x it.)
Joined: 16 Nov 2015 Posts: 6754 Location: UK, London, just across the river..
Posted: Mon Nov 11, 2019 4:40 Post subject:
add this to your startup script to disable the lights on your r7000.
for i in 2 3 8 9 12 13 17 18 ; do gpio enable $i ; done
for i in 14 15 ; do gpio disable $i ; done
Run this from the command line to disable the 4 LAN lights.
et robowr 0x0 0x18 0x1ff
et robowr 0x0 0x18 0x0
et robowr 0x0 0x1a 0x0
those work on my R7000 ...
otherwise a black scotch will do the job _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 58184 WAP
TP-Link WR1043NDv2 -DD-WRT 59171 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 59171 Gateway/DoT,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 59171 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 59171 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Dynalink DL-WRX36-DDWRT 59171
Broadcom
Netgear R7000 --DD-WRT 58976 Gateway/SmartDNS/DoT,AD-Block,IPsetFirewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
add this to your startup script to disable the lights on your r7000.
for i in 2 3 8 9 12 13 17 18 ; do gpio enable $i ; done
for i in 14 15 ; do gpio disable $i ; done
Run this from the command line to disable the 4 LAN lights.
et robowr 0x0 0x18 0x1ff
et robowr 0x0 0x18 0x0
et robowr 0x0 0x1a 0x0
those work on my R7000 ...
otherwise a black scotch will do the job
The problem is ‘et’ is not available anymore on BS build, so your last 3 commands won’t work.
I have the same problem since moving from <Kong> — and black scotch does work by the way:P
Alozarus: when I clarified that I tried many combinations of commands, I didn't list all the possibilities I tried in order to save space. I can say I tried several dozen variations of that particular script, since that's the one that's all over the internet. It's also wrong; GPIO pins 2 and 3 are inputs, not outputs, but what can I say...
I don't want to use scotch tape since I'll be using this router to connect computers under test, and I need to be able to see the link lights in that situation. Software control is possible, it just needs to be figured out.
dragonc: Yup, hence et.zip
kernel-panic69: Yep, I guess most of this is old news for the regulars here, or those more familiar with DD-WRT history.
That being said, if I search (including quotes) for the strings "0x0 0x10 0x0301" or "0x0 0x12 0x022" Google says no results were found, because it hasn't indexed this thread yet
All / noone in particular:
IIUC, Kong has just up and walked and is no longer maintaining his builds, right? In this is true, I don't really want to try that because I'd only have to switch/adjust to a different fork at next upgrade.
Does LED control really/definitely work in the latest versions of Kong/Tomato though? I'm *almost* of a mind to have a look, because if it is, that's really confusing - isn't the only difference the inclusion of the et command?
Joined: 08 May 2018 Posts: 15415 Location: Texas, USA
Posted: Thu Nov 14, 2019 2:52 Post subject:
I'd have to pull out my R7000 that is flashed with a test build for busybox updates and fire it up to check so you don't have to monkey around with it to say for sure, but last I knew, it was working. I gotta get back to working on that stuff, anyway _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
There is more to this LED puzzle than is apparent. In the Netgear firmware the leds can be all turned off, except for the power led. All the information provided so far for DDWRT shows all the leds turned off, except for the lan 1 led.
Why the discrepency? There must be a way to turn off lan 1...
I could be wrong but, from what I've read, the r6700v3 and the r7000 may be similar, so thought I'd share that I was able to get Ethernet Leds on ALL ports turned off, including the elusive port number 1.
I was able to upload et and get it working on a previous build (netgear-r6700v3-webflash-05-09-2020-r43099.bin), without ever getting eth port 1 turned off.
But with my recent update to the latest build (netgear-r6700v3-webflash-11-05-2021-r47618.bin at time of writing) I had to do a bit more discovery, as things seemed to have changed and were slightly different from my past experience.
Anyway, thought I'd leave this here in case it helps someone:
Note: most of you are way above and beyond with this stuff then I am, I just learned what bitwalk and disassembly was from this very post, for example and I got the et from this post as well but, thought I'd share just the same. If nothing else, for Netgear r6700v3, we (I) know now it's possible to get all LEDs off, at least.
I wanted to figure out how to reproduce the Genie behavior where you can turn most of the LEDs off.
and I don't know how many revisions I'd need to flash to properly bisect this (I'd assume tens to low hundreds, as I have no scoping hints).
, so I THINK that 
