Netgate SG-3100 LEDs

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.

wgstarks

@jchonig said in Netgate SG-3100 LEDs:

@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 /var/run/gw_leds.lock.
/usr/bin/lockf /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.

Just to be sure I understand, this will kill one run before it starts the next?

jchonig

@wgstarks No, this will prevent another from starting. And see the edit I'm going to make in a minute to add a timeout.

renegade

Great script! Thanks a lot for that!
I would have now monitored my VDSL and LTE line. Would be happy, if the last LED could pulsate as before :-)
It also would be great if their is a mechanism enabled which prevents the described „deadlock“ as i would like to decrease the interval/cronjob to maybe 15 or 30 seconds.

renegade

Update from my side: After almost 12h runninh the cron job the system became unresponsive.

jchonig

@renegade Are you using lockf in your cron script? That's supposed to prevent it from consuming resources.

I'm pretty sure the root problem is a kernel bug causing the sysctl and gpioctl commands to hang. I need to find the time to do some debugging.

renegade

@jchonig Not yet - I will give it a try I suppose :)