Shellcmd disable blue LED

[kburk]

Hello,
I hope this is the right place to ask this question, if not please let me know.

I have a Netgate 6100 and I am trying to disable the blue LED on the front of the device during boot. I have the command to do this and I can disable the LED via a ssh shell session or by using the "Command Prompt" section in the GUI, but if the device is rebooted the LED is enabled again.

To attempt disabling this during boot I am using the "Shellcmd" package, but I can't get it working. I have been unable to find anything in the logs indicating that the command failed.

Using the "Shellcmd" package settings GUI I added the command as seen below, but I found that the configuration file replaced the greater than sign > with >. Is this causing the problem? I'm thinking this is to avoid confusing the XML tags, but is the proper command actually being ran by the system or is there an escape character that should be used before the >? Any help would be appreciated.

This is the command I am attempting to run during boot.

echo 0 > /dev/led/blue1

If I download the xml configuration file I find the command is added into the config as follows within the <system> section.

<shellcmd>echo 0 &gt; /dev/led/blue1</shellcmd>

This is what the Shellcmd package settings looks like:
login-to-view

Thanks,
Kevin B

[kburk]

Sorry, this might not have been the right place to ask my question.

As an update, I ran a quick test and the > was not causing an issue. I'm guessing that the LED state is set later in the boot process and overwrites my shellcmd setting. This is my best guess.

I'll look into using a script with a delay or something to solve this, but I guess I'll just comment that it would be a nice feature to be able to disable the LED's from the pfSense Web Interface. The blue LED on the Netgate 6100 seems excessively bright and I'm not sure how useful it is. I assume that a steady blinking blue light means normal operation, but I'd rather just keep it off.

Thanks,
Kevin

[elvisimprsntr]

@kburk install CRON package and set up command to run as cron.

I believe pfsense CRON supports the use of "@reboot" in the minute field to schedule the process once upon reboot.

[kburk]

Thanks @elvisimprsntr.

I actually figured it out earlier this morning. It seems that the LED flashing is set later in the boot process so when using the shellcmd to disable the LED, it ended up being turned back on. Instead I created a script in /usr/local/etc/rc.d named disable_led.sh (and set executable chmod +x disable_led.sh). I added the following to have the LED disabled 60 seconds after the bootup which works perfectly.

#!/bin/sh
# Disable blue LED at boot
sleep 60
echo 0 > /dev/led/blue1

Thanks anyway for the help.
Kevin

[luckman212]

@kburk I tried to get Shellcmd to work for this too, since I couldn't stand the blinking blue LED (I think it's actually supposed to be a solid blue LED, but the led_normalize() function is failing on the 6100 -- I opened redmine #12545 about that...

In case you want a less-annoying alternate to just switching the LED off completely, here's what I use (slow blue LED crawl).

save as /usr/local/etc/rc.d/ledset.sh and chmod +x it:

#!/bin/sh
/bin/sleep 5
find /dev/led -type c | while read l; do echo 0 >$l; done
echo 'sJJjjjjjj' >/dev/led/blue3
echo 'sjjJJjjjj' >/dev/led/blue2
echo 'sjjjjJJjj' >/dev/led/blue1

[forum1]

@luckman212 said in Shellcmd disable blue LED:

...I couldn't stand the blinking blue LED (I think it's actually supposed to be a solid blue LED, but the led_normalize() function is failing on the 6100 -- I opened redmine #12545 about that...

@luckman212 I don't know if you noticed, but unfortunately your bug report got set as "Not a Bug" - Apparently due to the preliminary code analysis being inaccurate. This of course ignores the actual symptom you cited, which I agree is probably not functioning as intended. Given the current comments in the bug report it seems like a more accurate root cause might have been just within grasp, but that didn't happen and it looks like the baby may have been thrown out with the proverbial bathwater.

I don't know if there are other reports on this LED behavior or if it's even still an issue with the latest release (I have not upgraded yet and only have one 6100 available to work with), but if not it would be nice to have this properly "fixed" as I don't think it's as intended. Or if it is then the Netgate functional spec needs to be reviewed and brought up for debate, I guess, as it would be nice to not have to implement workarounds for something so basic.

[luckman212]

@forum1 I moved mine to a closet a little while ago so I can't even see the LEDs anymore. But I'll check and see if they're working differently now on the latest 22.05 snaps, which is what I am running.

[stephenw10]

The status LED is supposed to flash blue when it finished booting normally. During boot all three LEDs flash blue at a faster rate.
This matches the 2100/3100 behaviour though without the LED controller it cannot 'pulse' on the 6100 like it does there.

Steve

[forum1]

@stephenw10 said in Shellcmd disable blue LED:

The status LED is supposed to flash blue when it finished booting normally.

If this is truly by design then I'd ask that an enhancement request, or whatever it's called in Netgate vernacular, be raised. As someone that works with other Netgate models that don't have rhythmically flashing status lights for normal states, it would be nice to either have the default behavior changed or have a GUI option added to configure the behvaior. Some rationale (not exhaustive): If the unit is in an occupied space I find that folks are annoyed by the flashing, especially given how bright the LED is. Being a fanless unit it is more likely to be selected for occupied spaces. Also, as a general design philosophy for such equipment, I typically associate this sort of flashing with abnormal states, such as errors or alerts, and temporary not ready/transitory conditions like startup and shutdown - Things that may need attention.

[stephenw10]

You're not the first to ask.

https://redmine.pfsense.org/issues/12832

Add comments there if you like. More feedback always better.

Steve