That was really helpful, even though I mostly still don't understand most of the commands do. I don't have script.sh on my system (GL.iNet version of OpenWRT) so I put @abwezi's commands in my rc.local. Not sure if that is the right way to go, but it does wake the media server on access. It also generates tons of "Tue: not found" in my system log, from both of these lines:
Did you call the script from rc.local or paste it in there? If called from elsewhere, where do you suggest putting it so it is not overwritten on firmware updates?
you see, there is tick sign after = and at the end. those are required.
this code is an endless loop you should only put the code directly to rc.local if you run like this:
# /etc/rc.local
# whatever else in your rc.local
( code above starting from line PINGS_CNT ... ) &
or (better) create a new file called as you like (e.g. wakeplex.sh, set it is executable ) and call from rc.local as
# /etc/rc.local
# whatever else in your rc.local
/path/to/wakeplex.sh &
there is no right place to keep files between system upgrade, unless you have an external drive or another non-system partition. in order to keep it should add script's location to /etc/sysupgrade.conf.
Thanks! Those back ticks and the trailing ampersand were key for getting rid of the error messages and for avoiding that loop that blocked subsequent commands. The only error message left is referring to your addition:
nft insert rule inet fw4 forward iifname br-lan tcp dport 32400 ct state new counter log prefix \"PLEX Connection \"
This causes the log output:
PLEX Wake on LAN serevice was started.
wakeplex.sh: line 12: nft: not found
If I use the original firewall rules, the second one causes log output:
PLEX Wake on LAN serevice was started.
Object "FORWARD" is unknown, try "ip help"
Option "-I" is unknown, try "ip -help"
recent versions (last 2years roughly) are using nftables as firewall, which means nft should be available. older owrt versions were using iptables. ip definitely is wrong for sure.
Are you using GL.iNet's version of OpenWRT or have you flashed the device with OpenWRT downloaded directly from OpenWRT.org?
If it's the former then it appears you are using firmware that is not from the official OpenWrt project.
When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.
Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).
If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.
I read that GL's firmware uses nftables... strange. Ok, I have some digging to do on that end and regarding this forked package etherwake-nfqueue mentioned by @rwalli. Thanks!