Netgate SG-3100 LEDs

z4xh

I wrote some more comprehensive documentation on my blog, which explains the timings in more depth. https://www.zacharyschneider.ca/blog/post/2019/12/customizing-leds-netgate-sg-3100

Hope it helps!

jchonchi

I took some of the information in this article and wrote a script that sets the LED colors based on network interface state and bandwidth usage.

KnowbuddyYuno

@jchonchi Sounds useful. Does the script work as intended?

I'm a complete moron when it comes to coding, so my risk tolerance is near zero.

styxl

@jchonchi i am using the script, works like charm. Thanks

jchonig

Very helpful thread.

I re-wrote msf2000s script as a sh script and generalized it a bit.

I use the left (circult) and middle (square) LEDs to monitor my two WAN connections.

I also toned it down a bit so I don't need sunblock.

You can find it here

bldnightowl

@msf2000 This was working for a long time in 2.4.5 -- but doesn't seem to anymore in 21.02.

wgstarks

@bldnightowl said in Netgate SG-3100 LEDs:

@msf2000 This was working for a long time in 2.4.5 -- but doesn't seem to anymore in 21.02.

After reading the release notes I’m guessing this is the reason-


Several abandoned and deprecated packages have been removed, including:

OpenBGPD (use FRR instead)
Quagga OSPF (use FRR instead)
routed
blinkled
gwled

msf2000

@bldnightowl
What the crap is NetGate doing with version numbers? Breaking their own products? I don't plan to update past 2.4.5. Guess I'll read up on what's going on later.

As for my script, sorry, you are probably on your own if you upgrade to v21.

z4xh

@bldnightowl Check that you're using the right GPIO device:

sysctl dev.gpio | grep .led.

When I upgraded to 21.02/2.5, the GPIO device changed from 0 to 2 on my SG-3100.

@wgstarks The blinkled and gwled packages aren't needed for the SG-3100 LED driver, those are for controlling the LEDs on ALIX and WRAP platforms.

jchonig

@z4xh What is the relationship between the output of that command to the numbers I provide to gpioctl? I'll update my script to make use of that and test it on 2.4.5 while they figure out the issues with 21.02.

Thanks.

Jeff

z4xh

@jchonig This github commit explains it best: https://github.com/justdaniel-gh/sg3100customleds/commit/ddbf412cb1cf3ba32160972e2177c356611ff57f

jimp

The probe order of the GPIO devices changed in the newer version of FreeBSD since more of the on-board devices are supported now. It wasn't intentionally moved or anything.

stephenw10

Yes, it looks like the script doesn't set the gpio device so it defaults to using device 0 which is no longer valid. You need to set gpioctl to use /dev/gpioc2, for example:

/usr/sbin/gpioctl -f /dev/gpioc2 6 duty 0

Steve

jchonig

I've updated my script and put it in a git repo. I'm still only running it on 2.4.5 until 21.02 is stable on the SG-3100.

jchonig

I've updated my script for the gatewaystatus returned by pfSense+ 21.05 and to allow the specification of the gateways to monitor on the command line. It's no longer necessary to edit the script.

In my case the cron command looks like:

/root/gw_leds -v -a WAN_OTTC_DHCP -b WAN_EA_DHCP

Which means that LED a (left-most) monitors WAN_OTTC_DHCP gateway and LED b (middle) monitor WAN_EA_DHCP gateway.

jchonig

I bit more hacking on the script today.

I made it more modular.

I disable PWM mode on any LEDs we are using which disables the slow blink. Maybe I should make that configurable.

I also added -A, -B and -C options to set a fixed color for a given LED give a list of 3 comma-separated numbers. Mostly for testing.

Off to do non-computer stuff on a Saturday.

wgstarks

New script worked great. I only have one gateway so I used

/root/gw_leds -b WAN_DHCP -A 0,0,16 -C 0,0,16

This gave me light blue (undetermined) for first and last led and current status on the center led.

The only issue I had was that I couldn't remember how to upload a file to root.

SFTP of course. I just don't do it very often.

jchonig

@wgstarks I decided not to be too clear on that to make sure people knew enough of what they were doing to figure that out.

wgstarks

@jchonig I raised an issue on GitHub but I’m posting here as well. Looks like this script may be causing problems with large numbers of pipes being left open which results in a constant stream of errors

kern.ipc.maxpipekva exceeded; see tuning (7)

More details here and especially here.

jchonig

@wgstarks I think this will work to keep the script from starting if the previous run did not complete. This isn't a fix, but it will keep the system from failing

Change the cronjob to start with /usr/bin/lockf -s 1 /var/run/gw_leds.lock.

/usr/bin/lockf  -s 1 /var/run/gw_leds.lock /root/gw_leds -a WAN_OTTC_DHCP -b WAN_EA_DHCP

Or stop running the script.

The issue seems to be that the sysctl command is hanging and cron is starting the script again in 60 seconds.