Netgate SG-3100 LEDs

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 :)

wgstarks

@jchonig said in Netgate SG-3100 LEDs:

@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.

This worked for me for about 18 hours but now the system is completely locked up with the same error so lockf doesn’t appear to do the trick.

Edit: Here is the command I was using (just for reference)-

/usr/bin/lockf /var/run/gw_leds.lock /root/gw_leds -b WAN_DHCP -A 0,0,16 -C 0,0,16