Chicken or egg with netfilter LED trigger

[psherman]

@slh

But patching p910nd to poke /sys/class/leds/…/brightness might be an alternative (get_lock() and free_lock() look promising, as a lazy man's approach, lines 642 and 653 might be more specific).

That's a clever idea... but the effort invovled here is fairly significant (the patch would be easy, in theory, but there's a fair bit of work to setup the toolchain to then compile the file).

That said, this inspired me to look to see if there was a temporary lock file or any other indicators of activity... I could simply poll for a file and then turn the LED on or off accordingly. The latter is easy, the former seems like it would also require patching the source code.

@slh

Personally, I'd probably be lazy (and wouldn't look at the LEDs anyways)

I'm now leaning that way... lol. I was thinking it would be a reasonable indicator... but not worth that much effort.

@hnyman

This makes me wonder if it is supported by nftables. See the unsupported section.

Yeah... looks like it isn't fully supported. I wonder if it ever actually did work in LEDE.
Good find, though!

[hnyman]

@psherman

I wonder if it ever actually did work in LEDE.
Good find, though!

LEDE used the iptables/xtables based netfilter modules, while 22.03 and master use the fully nftables based netfilter.

[psherman]

What about 18.06? (yes, ancient)

[hnyman]

OpenWrt/LEDE used the iptables based firewall3 upto 21.02, and then from 22.03 onward the nftables baased firewall4.

You should have notived the rather extensive firewall4 discussions and PRs in 2021-2022

[psherman]

@hnyman

You should have notived the rather extensive firewall4 discussions and PRs in 2021-2022

Oh, yeah, I did . Just didn't know if there was a significant difference between 17.01 and 18.06 wrt how the netfilter functions worked...