Hello,
I've seen several posts around related to controlling the LEDs on an OpenWRT device whose switch has been migrated to DSA.
I understand that due to DSA you can't reasonably control the LEDs via software (if you want to see them indicate actual traffic), because the software no longer really knows how traffic flows through the switch.
However, I think a reasonable majority of users simply want to turn the LEDs off. To turn the LEDs off, it doesn't matter if you know (or don't know) whether traffic is passing through the switch, because you are not changing the light state based off of that event.
I would therefore like to ask - how difficult is it to allow non-traffic-based (or at the very least "all off") LED configurations on devices whose switch has been migrated to DSA?
For example the TP-Link Archer C7 v2 which is sort of a hybrid that hasn't really been migrated to DSA yet but doesn't have the LED options in last few releases of OpenWRT either - would you not consider adding at least the non-traffic-based LED control back to OpenWRT?
I despise all LEDs and other than maybe the power led being set to blink every 5 seconds or something, I don't really want to see any light coming off the router at all.
To all the people suggesting I block the lights off with a tape or similar - it used to be possible to turn off the leds via OpenWRT software. Why would such reasonably useful feature for peaceful non-disco night be taken away? What if I for example want to re-sell the router later on. I don't want to have to be cleaning out sticky tape from the header of the router...
If there is reasonably simple way of re-enabling the switch LED control for most devices (which used to support it previously) under the condition the only available control modes are those that aren't based off of traffic, could we please get this quite useful feature of OpenWRT back?
I can control the non-port LEDs and that works, of course. But it's not much help if the port LEDs make lightshow of my room...
I don't know how it is possible that I was able to control the LEDs on my previous version... it was I think chaos calmer? Yeah, it was "OpenWrt 18.06.1 r7258-5eb055306f"
It was a little sad for me when I upgraded because even the old config (to turn off the switch LEDs) was left in, only to mock me (because it couldn't be used on the new version of OpenWRT, of course).
Why is it no longer possible to do in the new version, I'll never know....
Here is the config which I used and which worked - to control the LEDs at runtime (in case you are interested):
config led 'led_usb1'
option name 'USB1'
option sysfs 'tp-link:green:usb1'
option interval '50'
option default '0'
option trigger 'usbport'
list port 'usb1-port1'
config led 'led_usb2'
option name 'USB2'
option sysfs 'tp-link:green:usb2'
option interval '50'
option default '0'
option trigger 'usbport'
list port 'usb2-port1'
config led 'led_wlan2g'
option name 'WLAN2G'
option sysfs 'tp-link:blue:wlan2g'
option default '0'
option trigger 'none'
config led 'led_wlan5g'
option name 'WLAN5G'
option sysfs 'tp-link:blue:wlan5g'
option default '0'
option trigger 'none'
config led
option default '0'
option trigger 'none'
option name 'LAN1'
option sysfs 'tp-link:blue:lan1'
config led
option default '0'
option trigger 'none'
option name 'LAN2'
option sysfs 'tp-link:blue:lan2'
config led
option default '0'
option sysfs 'tp-link:blue:lan3'
option trigger 'none'
option name 'LAN3'
config led
option default '0'
option name 'LAN4'
option sysfs 'tp-link:blue:lan4'
option trigger 'none'
config led
option default '0'
option name 'WAN'
option sysfs 'tp-link:blue:wan'
option trigger 'none'
config led
option trigger 'none'
option name 'QSS'
option sysfs 'tp-link:blue:qss'
option default '0'
config led
option default '0'
option name 'SYSTEM'
option sysfs 'tp-link:blue:system'
option trigger 'timer'
option delayon '5000'
option delayoff '5000'
If I'm not mistaken, back then it was based on the ar71xx target, now it's based on ath79 - a lot has changed behind the scenes. I don't know what has been ported and what not, maybe there is some driver interface to control the LEDs via entries in /sys or /proc, even if not via the standard /sys/class/leds directory.
A different "target", I see... but point remains the same - it was possible to control those leds at runtime, now it is not.
I guess as you said my only option is to look into custom compiling a version with the switch LEDs off. Or do you think there's a point in creating an issue @ official github repo with the functionality regression? I think a lot of people are interested in disabling the LEDs on their routers - heck even the official firmware now has a "night" mode. And the Archer C7 is a very popular device, even if a little dated.
I observed this "regression" in 23.05.0-rc1 on switches with hardware offloading (i.e. issue with the lights not flashing for offloaded frames). So the LAN port lights can no longer be controlled. In that case it's clear they won't revert it.
For some reason, the developers preferred that the lights should "flash accurately" - as opposed to merely being controllable.
Interesting enough, they didn't redo the WAN port.
The topic you linked to covers MT7530 switches only. Do you happen to know if a similar decision was made for QCA switches? That would definitely explain the changed behavior.
It's funny because most people care not for the flashing being accurate or not, in fact I would reckon most people just want to turn the bloody LEDs off
I just don't understand the option itself isn't there anymore. Like... at least make it "turn off" or "follow the switch decision". I don't mind even if I have to reboot to make it work...
fair enough, but how would you feel if they took the ability to make them blink correctly away and instead forced you to have them off at all times no matter what you wanted...
fair enough, but how would you feel if they took the ability to make them blink correctly away and instead forced you to have them off at all times no matter what you wanted...