'et robowr' Ethernet LED commands for R7xxx* don't work.

Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware
Author Message
i336_
DD-WRT Novice


Joined: 05 Nov 2019
Posts: 4

PostPosted: Mon Nov 11, 2019 4:13    Post subject: 'et robowr' Ethernet LED commands for R7xxx* don't work. Reply with quote
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 Cool

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 Smile 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 Very Happy 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 Very Happy (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 Wink, 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 Smile

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 if your DD-WRT version is *at least* a year old. There is yet no known/logical reason as to why. Mad

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 Smile 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 Mr. Green - I wish you the best of luck in not bricking your router, and that you succeed before your flash wears out. Smile (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 Smile, 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 Smile) 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.



httpd_set_led_settings.png
 Description:
 Filesize:  77.35 KB
 Viewed:  148 Time(s)

httpd_set_led_settings.png



libacos_set_led_settings.png
 Description:
 Filesize:  114.93 KB
 Viewed:  148 Time(s)

libacos_set_led_settings.png




Last edited by i336_ on Mon Nov 11, 2019 4:25; edited 1 time in total
Sponsor
i336_
DD-WRT Novice


Joined: 05 Nov 2019
Posts: 4

PostPosted: Mon Nov 11, 2019 4:16    Post subject: Reply with quote
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:  147 Time(s)

leddown.png



ledup.png
 Description:
 Filesize:  38.36 KB
 Viewed:  147 Time(s)

ledup.png




Last edited by i336_ on Mon Nov 11, 2019 4:27; edited 1 time in total
i336_
DD-WRT Novice


Joined: 05 Nov 2019
Posts: 4

PostPosted: Mon Nov 11, 2019 4:20    Post subject: Reply with quote
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.)



et.zip
 Description:

Download
 Filename:  et.zip
 Filesize:  5.25 KB
 Downloaded:  3 Time(s)

Alozaros
DD-WRT Guru


Joined: 16 Nov 2015
Posts: 2982
Location: UK, London, just across the river..

PostPosted: Mon Nov 11, 2019 4:40    Post subject: Reply with quote
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 Razz Razz

_________________
Atheros
TP-Link WR740Nv1 ------DD-WRT 33772 BS WAP/Switch (wired)
TP-Link WR1043NDv2 ----DD-WRT 41459 BS (AP,PPPoE,NAT,AD Blocking,AP Isolation,Firewall,Local DNS,Forced DNS,DoT)
TP-Link WR1043NDv2 ----DD-WRT 41517 BS (AP,NAT,AD Blocking,Firewall,Wi-Fi OFF,Local DNS,Forced DNS,DoT)
TP-Link WR1043NDv2 ----Gargoyle OS 1.11.0 (AP,NAT,QoS,Quotas)
Qualcomm/IPQ8065
2x Netgear R7800 -------DD-WRT 40270M 4.9 Kong (AP,NAT,AD-Blocking,AP&Net Isolation,VLAN's,Firewall,Local DNS,DNSCrypt-proxy v2 x2)
Broadcom
Netgear R7000 -------DD-WRT 40270M Kong (AP,NAT,VLAN,AD-Blocking,Firewall,Local DNS,Forced DNS,DoT)
------------------------------------------------------------------------------------------------
Stubby for DNS over TLS I DNSCrypt v2 via Entware by mac913
dragonC
DD-WRT User


Joined: 23 May 2015
Posts: 207

PostPosted: Mon Nov 11, 2019 10:45    Post subject: Reply with quote
Alozaros wrote:
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 Razz Razz


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
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 2318
Location: Texas, USA

PostPosted: Mon Nov 11, 2019 18:14    Post subject: Reply with quote
This is a useless thread unless you are running Kong builds or FreshTomato.
_________________
E4200 v1 DD-WRT 41517 mega (K3.x)
R7000P DD-WRT 40270M kongac
E4200 v1 FreshTomato 2019.3.273 beta
E4200 v1 FreshTomato 2019.3.development
R7000 FreshTomato 2019.3.development
E4200 v1 1.0.07.development
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 4208
Location: Netherlands

PostPosted: Mon Nov 11, 2019 18:30    Post subject: Reply with quote
kernel-panic69 wrote:
This is a useless thread unless you are running Kong builds or FreshTomato.


Well not entirely, he posted et.zip that can maybe used on recent builds where it is missing?

_________________
Routers:Netgear R7800, Netgear R6400v1, Netgear R6400v2, Linksys EA6900 (XvortexCFE), Linksys E2000 (converted WRT320N), WRT54GS v1.
Install guide Linksys EA6900: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=291230
OpenVPN Policy Based Routing guide: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=321686
Install guide R6400v2:http://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
OpenVPN Server Setup:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=318795
Install guide R7800: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 2318
Location: Texas, USA

PostPosted: Mon Nov 11, 2019 19:02    Post subject: Reply with quote
egc wrote:
kernel-panic69 wrote:
This is a useless thread unless you are running Kong builds or FreshTomato.


Well not entirely, he posted et.zip that can maybe used on recent builds where it is missing?


I probably overlooked that, since the bulk of this thread is "old news", perhaps lol. It must be the weather here. Or the stars and planets are askew.

_________________
E4200 v1 DD-WRT 41517 mega (K3.x)
R7000P DD-WRT 40270M kongac
E4200 v1 FreshTomato 2019.3.273 beta
E4200 v1 FreshTomato 2019.3.development
R7000 FreshTomato 2019.3.development
E4200 v1 1.0.07.development
i336_
DD-WRT Novice


Joined: 05 Nov 2019
Posts: 4

PostPosted: Thu Nov 14, 2019 2:46    Post subject: Reply with quote
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 Smile

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?

Appreciate the feedback.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 2318
Location: Texas, USA

PostPosted: Thu Nov 14, 2019 2:52    Post subject: Reply with quote
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 Embarassed
_________________
E4200 v1 DD-WRT 41517 mega (K3.x)
R7000P DD-WRT 40270M kongac
E4200 v1 FreshTomato 2019.3.273 beta
E4200 v1 FreshTomato 2019.3.development
R7000 FreshTomato 2019.3.development
E4200 v1 1.0.07.development
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum