Mark,
Thanks for the reply, I appreciate the clarification.
May I ask how you're turning the WAN LED to green in your setup? What
mechanism do you use to do it? I've been unsuccesful thus far but
perhaps I'm not trying the proper set of adjustments. More specifically
can you share your /etc/config/network and also /etc/config/system?
Adam
On 10/2/12 10:36 AM, Mark Mentovai wrote:
Adam Gensler wrote:
I recently acquired a Netgear WNDR3800. To date I've been playing
exclusively on an alix 2D13 platform so I have a few new things to
learn. In any case, I've been tinkering with the LEDs and I'm having
some trouble getting my head around a few things. Specifically:
1. How does one accurately control the WAN LED? /etc/config/network
has this:
[…]
Supposedly this controls the orange WAN LED. However, setting
"option led 0" does not turn the LED off as indicated. It stops
blinking but it doesn't turn off. How do I turn off the orange LED?
I don’t know if you can, then.
2. Why is the orange component of the WAN LED configured/controlled
via /etc/config/network yet the wan:green LED is controlled via
/etc/config/system? Is there some reason I'm not immediately
understanding? Is it because the orange LED for WAN isn't listed
under /sys/class/leds? This would lead me to believe that this is
controlled via some different mechanism than the green LED on the
hardware.
The original firmware for this router doesn’t use green/amber on the WAN
LED to indicate the same thing that it uses green/amber for on the LAN
switch port LEDs. For the LAN switch ports, the LED colors indicate link
speed. This is easily handled in hardware. For the WAN port, the LED
color indicates whether an Internet connection has been established. I
don’t recall whether the original firmware was probing some site or
whether it was just deciding it had connectivity when it obtained a DHCP
lease, but regardless of the mechanism it was using to make this
determination, it’s something that’s best handled in software.
Accordingly, for the WAN LED, the hardware was left to handle what it
does best (turning the LED on for link presence, and blinking it for
activity), and software handled the color.
(In my own builds, I mimic something close to the original firmware’s
meaning for the WAN LED by turning the LED green when a DHCP lease is
obtained or renewed, and amber when lost, via a hotplug action launched
from /lib/netifd/dhcp.script. For cases where WAN isn’t configured by
DHCP, I set the LED color based on the link speed when a link is
detected by ifplugd.)
3. Along with #2, why is the green LED pre-configured in
/etc/config/system by /etc/uci-defaults/leds on first boot? The
preconfiguration doesn't actually do anything. What is this for? Am
I missing something?
You’re correct, I don’t believe it actually does anything (and I’ve
removed it from my own builds). All it’s doing is setting the WAN LED to
“not green” (thus amber), but I think that’s the default. Having this in
/etc/config/system does provide a template for you to modify if you want
to change the behavior of the LED, although given the
hardware-software-hybrid nature of that LED, it’s less useful than for
LEDs strictly under software control.
4. The wifi adapters, ath9k-phy0 and ath9k-phy1 apparently default
to the respective "phy[0|1]tpt" trigger. This also isn't in
/etc/config/system. It seems to happen elsewhere, but I haven't
found the place that controls this. How is this accomplished? Is
this some ath9k driver default?
It is. This happens in
compat-wireless/drivers/net/wireless/ath/ath9k/init.c.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
