I've run into an issue while attempting to setup a netfilter based LED trigger.
Specifically, I'm trying to setup a trigger to blink an LED when I have an incoming print job on my OpenWrt print server. I'm following the led configuration > net filter dcumentation... but when I try to setup the trigger, I get an error. (for now, I'm just using the ssh example and will change it later for the printer on port 9100)
root@PandoraPrinter:~# iptables -A INPUT -p tcp --dport 22 -j LED --led-trigger-id ssh --led-delay 1000
iptables v1.6.2: unknown option "--led-trigger-id"
Try `iptables -h' or 'iptables --help' for more information.
I found a really old thread where @anomeome mentioned a chicken or egg situation... you can't set the netfilter trigger until you have the led trigger available, but of course you can't add or set the trigger type until until it is defined elsewhere.
But that thread old didn't seem to have a resolution...Any ideas of how to solve this?
FWIW, I'm running this on a very old version of OpenWrt (18.06.9)... in this case, the device is too small to run a more recent version. The device is wired to a trusted network with wifi disabled. It has no exposure to the internet and the only services running are ssh and p910nd.
I don't see it in the iptables -h output (which is no surprise)... is that help output dynamic insofar as adding a kmod will add additional options to the help info?
iptables -h
iptables v1.6.2
Usage: iptables -[ACD] chain rule-specification [options]
iptables -I chain [rulenum] rule-specification [options]
iptables -R chain rulenum rule-specification [options]
iptables -D chain rulenum [options]
iptables -[LS] [chain [rulenum]] [options]
iptables -[FZ] [chain] [options]
iptables -[NX] chain
iptables -E old-chain-name new-chain-name
iptables -P chain target [options]
iptables -h (print this help information)
Commands:
Either long or short options are allowed.
--append -A chain Append to chain
--check -C chain Check for the existence of a rule
--delete -D chain Delete matching rule from chain
--delete -D chain rulenum
Delete rule rulenum (1 = first) from chain
--insert -I chain [rulenum]
Insert in chain as rulenum (default 1=first)
--replace -R chain rulenum
Replace rule rulenum (1 = first) in chain
--list -L [chain [rulenum]]
List the rules in a chain or all chains
--list-rules -S [chain [rulenum]]
Print the rules in a chain or all chains
--flush -F [chain] Delete all rules in chain or all chains
--zero -Z [chain [rulenum]]
Zero counters in chain or all chains
--new -N chain Create a new user-defined chain
--delete-chain
-X [chain] Delete a user-defined chain
--policy -P chain target
Change policy on chain to target
--rename-chain
-E old-chain new-chain
Change chain name, (moving any references)
Options:
--ipv4 -4 Nothing (line is ignored by ip6tables-restore)
--ipv6 -6 Error (line is ignored by iptables-restore)
[!] --protocol -p proto protocol: by number or name, eg. `tcp'
[!] --source -s address[/mask][...]
source specification
[!] --destination -d address[/mask][...]
destination specification
[!] --in-interface -i input name[+]
network interface name ([+] for wildcard)
--jump -j target
target for rule (may load target extension)
--goto -g chain
jump to chain with no return
--match -m match
extended match (may load extension)
--numeric -n numeric output of addresses and ports
[!] --out-interface -o output name[+]
network interface name ([+] for wildcard)
--table -t table table to manipulate (default: `filter')
--verbose -v verbose mode
--wait -w [seconds] maximum wait to acquire xtables lock before give up
--wait-interval -W [usecs] wait time to try to acquire xtables lock
default is 1 second
--line-numbers print line numbers when listing
--exact -x expand numbers (display exact values)
[!] --fragment -f match second or further fragments only
--modprobe=<command> try to insert modules using this command
--set-counters PKTS BYTES set the counter during insert/append
[!] --version -V print package version.
For completeness, this is what I see when I check the modinfo (essentially the same, I think, except that it doesn't have the name field -- is that the problem here??
What happens if you modprobe xt_LED? (well, given the old kernel, you may have to insmod it and its dependencies, modprobe and module loader behaviour isn't that old, for OpenWrt).
Disclaimer: general purpose linux (my OpenWrt systems are current master, with fw4, so loading iptables modules would be a tad difficult).
$ ls -al /sys/module/ | grep -i led
drwxr-xr-x 5 root root 0 9. Feb 20:27 ledtrig_audio
drwxr-xr-x 5 root root 0 10. Feb 04:44 xt_LED
FWIW, I get the same error on a 22.03.3 system with iptables and kmod-ipt-led installed.
root@OpenWrt:~# iptables -A INPUT -p tcp --dport 22 -j LED --led-trigger-id ssh
--led-delay 100
iptables v1.8.7 (nf_tables): unknown option "--led-trigger-id"
Since --led-trigger-id is the offending arguement, there must be some other way we're supposed to assign the trigger... but even the code above seems to indicate that this is the right syntax.
That may be.... but given the space constrants on the print server, I'm guessing no -full packages will fit.. lol.
Presumably it worked back in the days of LEDE17.01 based on the documenation... maybe it broke in 18+ and nobody noticed or cared to fix it?
Since this seems like it might be a dead end... any other ideas for my intended goal?
I'd like to have the WPS LED light up (or blink) as traffic comes into the P910nd print server.
The idea I was trying was to use iptables + kmod-ipt-led to capture traffic on port 1900 and use that as the LED trigger. Obviously that isn't working because iptables is throwing the error. Is there any other way to form a trigger based on activity through P910nd?
Personally, I'd probably be lazy (and wouldn't look at the LEDs anyways)
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).
