Some more detail regarding automatic WoL on Plex access

I read this thread Configuring Wake on Lan to occur during Plex requests nftables with much interest, but it was closed already and I wasn't able to follow the solution.

Perhaps user @abwezi is still around and could add some detail to the solution he found. Where does this bash script need to go:

Same question for the firewall config posted by @grrr2 ...


first of all I don't use this script so please contact with original author if it may not work as expected. or if it does work as expected.

here is the firewall related part which should be replaced by the nftables rules.

as far as i see this script has two sections:

  1. set firewall rules to mark plex related traffic: adding logging which will be visible in syslog
  2. then there is a continous loop waiting for the log messages appear in syslog then accordingly wake plex server

so probably the idea is to run this script in the background ( &) started from CLI. it is not a service.

hope it helps.

That was really helpful, even though I mostly still don't understand most of the commands do. I don't have 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:

DST=echo $LOG_LINE | grep -Fo "DST=$SRV_IP"
DPT=echo $LOG_LINE | grep -Fo "DPT=$SRV_PORT"

Also, the log file /var/log/wol never gets created on my system. Not sure if any of that is to be expected.

Yes I did use rc.local for executing the scripts that's correct. I don't see those same errors in my log though, not sure about that

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?

the quoted script format looks weird it looks like a formatting problem as if i copy the content it is ok:

DST=`echo $LOG_LINE | grep -Fo "DST=$SRV_IP"`
DPT=`echo $LOG_LINE | grep -Fo "DPT=$SRV_PORT"`

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., set it is executable ) and call from rc.local as

# /etc/rc.local
# whatever else in your rc.local
/path/to/ &

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

what version of owrt and device you use?

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.

OpenWrt 21.02-SNAPSHOT
GL Beryl AX

So I should use iptables, but there is something wrong with these two lines?

Are you using GL.iNet's version of OpenWRT or have you flashed the device with OpenWRT downloaded directly from

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

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. 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.

Sorry, I'm on the way and only cross-reading this topic.
For me etherwake-nfqueue worked perfectly without scripts.

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!