LED issues #4

nitroshift · 2014-08-29T08:09:36Z

E-sata LED stays ON, even though nothing is plugged in the e-sata port and the WPS keeps blinking at all times. Also, WAN MAC address stays set at 00:00:00:00:00.

Chadster766 · 2014-08-29T08:30:19Z

I will try adding the below code posted by forum user nyt:

--- a/attitude_adjustment/target/linux/armadaxp/base-files/usr/sbin/wan_monitor
+++ b/attitude_adjustment/target/linux/armadaxp/base-files/usr/sbin/wan_monitor
@@ -64,10 +64,12 @@ conn_type_dynamic() {
if [ $ping_status -ne 0 ]
then
wan_amber on

                  wan_white off
                #echo "PING FAILED:" $LINKPING $ping_status
                /usr/bin/logger "PING FAILED"
        else
                wan_white on

                  wan_amber off
                #echo "PING OK:" $LINKPING $ping_status
        fi
fi

nitroshift · 2014-08-29T15:33:26Z

That takes care of the WAN LED status. What about the other 2 and the MAC address issue?

Chadster766 · 2014-08-29T15:47:20Z

Yes I will be looking into those as well. It would be better if they were separated out as individual issues for track completed work.

nitroshift · 2014-08-29T16:54:40Z

Ok, this issue remains about LED's. I'm gonna create another thread for the MAC address.

Regards,
nitroshift

Chadster766 · 2014-08-29T16:55:27Z

Thanks :)

Chadster766 · 2014-08-30T15:10:02Z

I'm coping your solution post to here for quick reference.

For noob-ish users like me.

Until Chadster gets the chance to update his firmware, you can sort the LED lighting issue as follows:

WARNING!!! Modifying files or deleting them may render your device unusable (commonly referred to as "bricking").
Get WinSCP from here: http://winscp.net/eng/download.php
Open a SCP connection to your router with WinSCP.
Navigate to /usr/sbin folder.
Right click on "wan_monitor" file and select "EDIT"
After line 66 create a new line and insert this code:

```
                  wan_white off
```

After line 71 create a new line and insert this code:

```
                  wan_amber off
```

For those who use a PPPoe connection, edit line 31 so it reads

WAN_IF=pppoe-wan

Save the opened file.
Reboot.

Good luck!

Chadster766 · 2014-08-30T16:08:53Z

I think LED solution for PPPoe isn't going to work well in the long run. We need code that sets WAN_IF to the right wan interface configured.
Ex: eth1, pppoe-wan, ...

Chadster766 · 2014-08-30T17:46:19Z

Currently the wan_monitor script pings heartbeat.belkin.com to see if the internet connection is up. I think a better best practice would be to have it ping the Default Gateway instead.

nitroshift · 2014-08-30T19:42:19Z

After modifying wan_monitor file per my instructions above, the issue remains open ONLY for e-sata led staying ON. WAN LED functions correctly and the WPS LED stays OFF.

nitroshift

PS. For PPPoes users it is safe to remove wan6 interface altogether.

Chadster766 · 2014-08-30T20:40:54Z

But won't the internet LED be amber for PPPoe internet connections unless the user manually goes in and changes WAN_IF to "WAN_IF=pppoe-wan"? Wouldn't it show amber for all other types of internet connections other than DHCP Client and Static Address?

If it's too big a job for the next release we can just get the Internet LED to work for DHCP Client and Static Address internet connections in the meantime ☺️

nitroshift · 2014-08-30T21:39:14Z

You are right about the WAN LED and different connection methods but it is fine for me to leave it set up for DHCP and Static addresses, as long as the instructions for PPPOE users how to modify the WAN_IF part are posted and visible. And should we sort out the e-sata LED issue, this firmware is stable enough for every day use.

nitroshift · 2014-08-31T15:50:32Z

I haven't found anything related to esata in any conf files, HOWEVER I came across IEEE1394 files. Could these relate to the esata port handling?

Chadster766 · 2014-08-31T16:32:48Z

I'm not sure about the IEEE1394 file but I will look into it.

The Internet LED is important and it needs to work properly. I'm looking for script code to find the interface used for the Internet connection and set WAN_IF to it. This should be fairly easy but I can't move on to the eSATA LED issue without it.

Chadster766 · 2014-09-01T05:56:28Z

I found the command to set WAN_IF but can't test it since I don't have PPPoe or another type of internet connection. I did have a testing platform for different types of internet connection but I turned it into my OpenWRT development platform 😄

WAN_IF=`uci get network.wan._orig_ifname`

nitroshift · 2014-09-01T06:19:45Z

I will test it when I get home, in about 7 hours and will update this issue with my findings.

Chadster766 · 2014-09-01T06:27:33Z

I tested it and it works!

Let's move onto the eSATA LED.

Chadster766 · 2014-09-01T06:28:11Z

If you can test on PPPoe that would be great.

nitroshift · 2014-09-01T06:36:03Z

I will when I get home. I have updated wan_config file but will see the results when I get home.

Chadster766 · 2014-09-01T15:13:20Z

In the same location wan_monitor file is in the file to control all LED's.

ledctrl led_esata on
ledctrl led_esata off

Now it's just a matter of finding out where to put the commands. I don't have an e-sata drive to test with.

nitroshift · 2014-09-01T17:08:28Z

WAN_IF=uci get network.wan._orig_ifname works on PPPoe too. leds_monitor refuses to display anything readable when opened with notepad++.

Chadster766 · 2014-09-01T17:27:32Z

Great, if "WAN_IF=uci get network.wan._orig_ifname " works for PPPoe it should work for all other WAN types. This will be included in the next release.

Chadster766 · 2014-09-01T17:29:49Z

We can easily turn on and off the esata LED but I would like it to function properly. Do you have an esata drive for testing?

Chadster766 · 2014-09-01T17:34:37Z

I finally checked the IEEE1394 file you mention and I think that might be it.
/etc/hotplug.d/ieee1394/10-ieee1394

nitroshift · 2014-09-01T17:42:02Z

That is the file I was talking about too, but unfortunately I don't have an esata drive at home, I have a couple at work though and I'll bring an enclosure tomorrow at home with a spare blank hard-disk.

Chadster766 · 2014-09-01T17:53:09Z

Thanks much appreciated 😃

nitroshift · 2014-09-01T18:21:11Z

If you have any modifications to the 10-ieee1394 file, please post them, I've ran to the office and got the esata enclosure connected to the router.

Chadster766 · 2014-09-01T18:55:11Z

How does the LED behave with the enclosure? I'm guessing it doesn't change. I will write the LED control script for 10-ieee1394 shortly.

nitroshift · 2014-09-01T18:56:43Z

It doesn't matter whether the enclosure is connected or not, esata LED stays ON.

nitroshift · 2014-09-01T20:43:29Z

Found something in /sys/class/leds/tlc59116:led_esata/

Chadster766 · 2014-09-01T20:51:02Z

Yes that's what the other script send data too for LED control (the hardware layer API).

nitroshift · 2014-09-11T04:42:42Z

I'm working on it.

Chadster766 · 2014-09-11T13:28:27Z

You might want to look in the Belkin patch submissions regarding led fixes and their implementation for clues. I'm not sure the esata led works in the stock firmware other than being turned off.

https://github.com/jimmychungbelkin/Mamba/tree/master/barrier_breaker/belkin/patch_submission

nitroshift · 2014-09-11T16:06:36Z

I looked into those then had an idea: is it possible to have a console output in real time while booting in which case we can see the exact process that triggers the e-sata LED to light up?

Chadster766 · 2014-09-11T16:20:49Z

The USB to TTL has console boot output but it's not much different the dmesg.

kmschaefer · 2014-09-11T18:06:32Z

I found this in the system log:

[ 168.234083] leds-tlc59116: Using tlc59116 16-bit LED driver at slave address 0x68
[ 168.241603] leds-tlc59116 0-0068: setting platform data
[ 168.246979] Registered led device: tlc59116:wan_amber
[ 168.247107] Registered led device: tlc59116:wan_white
[ 168.247236] Registered led device: tlc59116:led_2g
[ 168.247367] Registered led device: tlc59116:led_5g
[ 168.247496] Registered led device: tlc59116:led_esata
[ 168.247624] Registered led device: tlc59116:led_usb2
[ 168.247759] Registered led device: tlc59116:led_usb31
[ 168.247891] Registered led device: tlc59116:led_usb32
[ 168.248021] Registered led device: tlc59116:wps_white
[ 168.248161] Registered led device: tlc59116:wps_amber

If you look under /sys/devices/platform/mv64xxx_i2c.0/i2c-0/0-0068/leds/tlc59116:led_esata, you will see the brightness file is already set to 0. Also, /usr/sbin/ledctrl led_esata off or on has no effect. The brightness file gets changed from 0 to 255 and back again, but somewhere the mapping of the brightness file to the LED is not correct.

Chadster766 · 2014-09-11T18:29:09Z

I noticed that too. I'm able to login to the Linksys stock firmware and turn the LED's on and off except the esata. Which makes me wonder if it works in any firmware other than to be turned off.

nitroshift · 2014-09-11T19:08:16Z

On stock firmware the esata LED works correctly.

Chadster766 · 2014-09-11T19:14:24Z

Interesting thanks for confirming that. Do you have an USB to TTL cable? I can give you direction on how to log into the stock firmware.

kmschaefer · 2014-09-11T22:45:51Z

Here is my final 10-usb script. Is there a way I can get you the actual file to incorporate in the image?

#!/bin/sh

Copyright (C) 2009 OpenWrt.org

case "$ACTION" in
add)
# update LEDs
case "$PRODUCT" in
"1d6b")
# Ignore base USB hardware
;;
)
case "$DEVPATH" in
*"usb1")
# USB 1.1 or 2.0 device added to USB 1
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' added to USB 1"
#/usr/sbin/ledctrl led_usb2 on
# The default brightness of 255 on my USB 1 is too bright, so setting it to 60
echo "60" > /sys/class/leds/tlc59116:led_usb2/brightness
;;
"usb3")
# USB 1.1 or 2.0 device added to USB 2
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' added to USB 2"
/usr/sbin/ledctrl led_usb31 on
;;
"usb4")
# USB 3.0 device added to USB 2
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' added to USB 2"
/usr/sbin/ledctrl led_usb31 on
/usr/sbin/ledctrl led_usb32 on
;;
esac
;;
esac
;;
remove)
# update LEDs
case "$DEVPATH" in
"usb1")
# USB 1.1 or 2.0 device removed from USB 1
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' removed from USB 1"
/usr/sbin/ledctrl led_usb2 off
;;
"usb3")
# USB 1.1 or 2.0 device removed from USB 2
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' removed from USB 2"
/usr/sbin/ledctrl led_usb31 off
;;
"usb4")
# USB 3.0 device removed from USB 2
/usr/bin/logger -t hotplug-usb "Devpath '$DEVPATH' removed from USB 2"
/usr/sbin/ledctrl led_usb31 off
/usr/sbin/ledctrl led_usb32 off
;;
esac
;;
esac

Chadster766 · 2014-09-12T00:42:06Z

Does this solve the esata led issue as well?

I will include this in the next release along with the internet led fix. You could add it to your image as a patch in the target directory possibly.

kmschaefer · 2014-09-12T01:20:09Z

This is only to make the USB LEDs work.

I added some logger lines to /etc/hotplug.d/ieee1394/10-ieee1394, but I did not see any entries when I connected and disconnected my eSATA drive. The system log did show notices from the kernel that the drive was attached, but the hotplug script was never called.

kmschaefer · 2014-09-12T01:20:37Z

And thanks for adding it to the next release. I look forward to testing it.

Chadster766 · 2014-09-12T02:32:07Z

To see how the Linksys stock firmware controls the esata led you might want look at their WRT1900AC GPL Tar file.
http://support.linksys.com/en-us/gplcodecenter
WRT1900AC_FW_v1.1.8.161917_SP2.tar

kmschaefer · 2014-09-12T14:28:41Z

This file WRT1900AC_FW_v1.1.8.161917_SP2/src/mod_bdutil/platform/mrvl_armada/leds.c is the only one with eSATA stuff in it.

This info might be useful:

/* Activity blinking interrups */
#define USB1_IRQ 45
#define USB2_IRQ 58
#define ESATA_IRQ 55
#define WIFI24G_IRQ 59
#define WIFI5G_IRQ 60

/*
eSata LED (MPP46)
MPP46 is in group 5. Group 5 contains 40 - 47, so 46 is in the 7th
position, bits 24:27.

Setting MPP46 to 0x0 will select GPIO control.
Setting MPP46 to 0x4 will select eSata HW control.
*/
#define LED_ESATA_MPP46_OFFSET MPP_CONTROL_REG(5)
#define LED_ESATA_MPP46_MASK (0x0F000000)
#define LED_ESATA_GPIO_CONTROL (0x00000000)
#define LED_ESATA_HW_CONTROL (0x04000000)

kmschaefer · 2014-09-12T14:31:35Z

And:

/*
eSata GPIO (GPIO46)
GPIO46 is group 1, bit 14.
*/
#define LED_GPIO46_MASK (0x00004000)
#define LED_GPIO46_OUTPUT_OFFSET (GPIO_GROUP1_BASE + GPIO_DATA_OUT)
#define LED_GPIO46_ENABLE_OFFSET (GPIO_GROUP1_BASE + GPIO_DATA_OUT_ENABLE)

nitroshift · 2014-09-12T18:14:46Z

Shouldn't one line that selects the control section be uncommented?

kmschaefer · 2014-09-12T18:32:03Z

Those are just notes. This stuff is from the C file in the Linksys stock firmware. There are a couple methods that turn the LED on and off, but I think we need the mapping stuff for Mamba to be corrected.

Chadster766 · 2014-09-12T18:35:29Z

Yes it's odd that they commented out the line below:
eSata GPIO (GPIO46)

kmschaefer · 2014-09-12T18:39:51Z

That isn't a setting. It is just information about which group it is in. The code talks about how setting the groups is what makes the LEDs function.

nitroshift · 2014-09-17T05:28:53Z

As far as I'm concerned the esata LED issue is closed as I'm using an external HDD hooked up to the router via esata :D

FCS001FCS · 2014-12-27T22:57:43Z

FYI
In latest Rev AAv1.0.8 most of the LEDs seem to be worling but eSATA LED is always on even with no drive attached to that connection. Tried USB 1 & 2 and they work as they should but I do not have an eSATA drive to see if a toggle (connect/disconnect) will affect the eSATA LED. eSATA LED comes on at boot-up and stays on even with nothing pluged-in to that eSATA/USB1 connector.

nitroshift · 2014-12-28T07:49:56Z

The E-sata led issue is still open.

Chadster766 · 2014-12-28T08:50:48Z

We have a solution for the esata led but it's a little complex and I need to do some testing first.

Chadster766 · 2015-08-18T20:07:36Z

I'm going to start working on this issue again.

Tez-187 · 2015-10-16T10:17:32Z

Thanks for reopening this issue keep up the good work

ppseprus · 2021-08-22T22:51:50Z

Hey All!

Although this one is closed, I have not found any other place to report these...
If you could refer me to some other thread, I'd really appreciate that!

I have a relatively new Linksys wrt1900ACS and

1) the power, WAN, 2.5GHz and 5GHz white LEDs are all dimmed like you talked above

Running OpenWRT, I can set the LED to simply stay on, and with the following command, I can verify that brightness is at its brightest

vim /sys/class/leds/pca963x:shelby:white:wan/brightness
# 255

Using the :amber LED instead (where available), one can see that the brightness issue only affects the white ones.

2) the triggers of some LEDs cannot be changed

a) Using LuCI, I'm trying to set different triggers for eg. the 2.5 and 5GHz LEDs. For example to simple stay on. But the LEDs default to their normal config and flicker instead.

b) Additionally, while there are no named LEDs for the 4 UTP ports, there are seven unnamed LEDs, which also cannot be turned on:

pca963x:0:68:10
pca963x:0:68:11
pca963x:0:68:12
pca963x:0:68:13
pca963x:0:68:14
pca963x:0:68:15
pca963x:0:68:4

Thank & regards,
Peter

Chadster766 mentioned this issue Oct 12, 2014

Dev Meeting #43

Closed

Chadster766 closed this as completed Aug 17, 2015

Chadster766 reopened this Aug 18, 2015

Chadster766 closed this as completed Feb 14, 2020

LED issues #4

LED issues #4

Comments

nitroshift commented Aug 29, 2014

Chadster766 commented Aug 29, 2014

nitroshift commented Aug 29, 2014

Chadster766 commented Aug 29, 2014

nitroshift commented Aug 29, 2014

Chadster766 commented Aug 29, 2014

Chadster766 commented Aug 30, 2014

I'm coping your solution post to here for quick reference.

Chadster766 commented Aug 30, 2014

Chadster766 commented Aug 30, 2014

nitroshift commented Aug 30, 2014

Chadster766 commented Aug 30, 2014

nitroshift commented Aug 30, 2014

nitroshift commented Aug 31, 2014

Chadster766 commented Aug 31, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 1, 2014

nitroshift commented Sep 1, 2014

Chadster766 commented Sep 1, 2014

nitroshift commented Sep 11, 2014

Chadster766 commented Sep 11, 2014

nitroshift commented Sep 11, 2014

Chadster766 commented Sep 11, 2014

kmschaefer commented Sep 11, 2014

Chadster766 commented Sep 11, 2014

nitroshift commented Sep 11, 2014

Chadster766 commented Sep 11, 2014

kmschaefer commented Sep 11, 2014

Copyright (C) 2009 OpenWrt.org

Chadster766 commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

Chadster766 commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

nitroshift commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

Chadster766 commented Sep 12, 2014

kmschaefer commented Sep 12, 2014

nitroshift commented Sep 17, 2014

FCS001FCS commented Dec 27, 2014

nitroshift commented Dec 28, 2014

Chadster766 commented Dec 28, 2014

Chadster766 commented Aug 18, 2015

Tez-187 commented Oct 16, 2015

ppseprus commented Aug 22, 2021

1) the power, WAN, 2.5GHz and 5GHz white LEDs are all dimmed like you talked above

2) the triggers of some LEDs cannot be changed

a) Using LuCI, I'm trying to set different triggers for eg. the 2.5 and 5GHz LEDs. For example to simple stay on. But the LEDs default to their normal config and flicker instead.

b) Additionally, while there are no named LEDs for the 4 UTP ports, there are seven unnamed LEDs, which also cannot be turned on: