|
|
- # OpenWrt package feed for etherwake-nfqueue
-
-
- ## Wake up computers on netfilter match
-
- This repository contains the OpenWrt package feed for
- [etherwake-nfqueue](https://github.com/mister-benjamin/etherwake-nfqueue),
- a fork of the **etherwake** Wake-on-LAN client, with support to send magic
- packets only after a queued packet is received from the Linux *nfnetlink_queue*
- subsystem.
-
- When running **etherwake-nfqueue** on a residential gateway or other type of
- router, it can wake up hosts on its network based on packet filtering rules.
-
- For instance, when your set-top box wants to record a TV programme and
- tries to access a network share on your NAS, which is in sleep or standby mode,
- **etherwake-nfqueue** can wake up your NAS. Or when you set up port forwarding
- to a host on your home network, **etherwake-nfqueue** can wake up your host
- when you try to access it over the Internet.
-
- The documentation below is mostly OpenWrt specific. For more information on
- etherwake-nfqueue itself and use case examples, please consult its
- [Readme](https://github.com/mister-benjamin/etherwake-nfqueue/blob/master/README.md).
-
-
- ## Building the package
-
- Currently, no pre-built packages are provided. The following assumes that you
- already have a working OpenWrt build system for your target device.
-
- If you haven't, you can follow one of these guides:
-
- * If you only want to compile packages, and no firmware image:
- [Build system – Installation](https://openwrt.org/docs/guide-developer/build-system/install-buildsystem) and
- [Using the SDK](https://openwrt.org/docs/guide-developer/using_the_sdk)
-
- * To quickly build a firmware image off a development snapshot:
- [Quick Image Building Guide](https://openwrt.org/docs/guide-developer/quickstart-build-images)
-
- * Or when you are completely new to using build systems:
- [Beginners guide to building your own firmware](https://openwrt.org/docs/guide-user/additional-software/beginners-build-guide)
-
- ### Dependencies
-
- **etherwake-nfqueue** depends on these OpenWrt packages:
-
- * libnetfilter-queue
- * iptables-mod-nfqueue
-
- They will be automatically selected and compiled for you. If they are not
- installed on your target device, *opkg* will try to resolve dependencies with
- packages in the repositories.
-
- ### Adding the package feed
-
- First, you need to add the **etherwake-nfqueue** package feed to your build
- system. In the root directory of your OpenWrt build system, find the file
- *feeds.conf* (or *feeds.conf.default* if the former shouldn't exist) and add
- the following line to it:
-
- ```
- src-git ethernfq https://github.com/mister-benjamin/etherwake-nfqueue-openwrt.git
- ```
-
- Then update and install the package feed:
- ```
- user@host:~/openwrt$ scripts/feeds update ethernfq
- user@host:~/openwrt$ scripts/feeds install -a -p ethernfq
- ```
-
- After that, enter OpenWrt's configuration menu
- ```
- user@host:~/openwrt$ make menuconfig
- ```
- and enable **etherwake-nfqueue** in the **Network** sub-menu. It can either be selected
- as built-in (\*) or module (M), depending on your decision to include it into a
- firmware image or just build the *opkg* package for installation.
-
- Then you should be able to compile the package:
- ```
- user@host:~/openwrt$ make package/etherwake-nfqueue/compile
- ```
-
- The path of the resulting package depends on your selected *Target System*.
- In case of the Linksys WRT1200AC, it can be found here:
- ```
- bin/packages/arm_cortex-a9_vfpv3/ethernfq/etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk
- ```
-
-
- ## Installation
-
- One way to install the package is by simply copying it over to the device with *scp*:
- ```
- user@host:~$ scp etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk root@gateway:~
- ```
- And then, install it on the device:
- ```
- root@gateway:~# opkg install etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk
- ```
-
-
- ## Configuration
-
- ### WoL Targets
-
- After a fresh installation, no target is configured. Targets are referred
- to as the hosts to wake up. Multiple targets can coexist.
-
- Targets can be configured with OpenWrt's UCI.
-
- For example, to add a target called **nas**, with MAC address
- **00:25:90:00:d5:fd**, which is reachable over the VLAN configured
- on **eth0.3**, issue this command sequence on your router:
-
- ```
- uci add etherwake-nfqueue target
- uci set etherwake-nfqueue.@target[-1].name=nas
- uci set etherwake-nfqueue.@target[-1].mac=00:25:90:00:d5:fd
- uci set etherwake-nfqueue.@target[-1].interface=eth0.3
- uci commit
- ```
-
- For each target, one instance of **etherwake-nfqueue** will be started.
-
- Each instance should bind to a different *nfnetlink_queue*. A queue can
- be referenced by its queue number. Counting starts from 0, which is the default.
- To use a different queue, provide the **nfqueue_num** option. The
- following could have been added to the sequence above to use queue 1 instead
- of 0:
-
- ```
- uci set etherwake-nfqueue.@target[-1].nfqueue_num=1
- ```
-
- The necessity of a queue number will probably become clear, when the iptables
- rules are configured in section [Setup firewall rules](#setup-firewall-rules).
-
- The full list of options for a target is:
-
- | Option | Required | Description |
- | ----------- | -------- | ------------------------------------------------ |
- | name | no | Name of the target, e.g. name=example |
- | mac | yes | MAC address of the host to wake up, e.g. mac=00:22:44:66:88:aa |
- | nfqueue_num | no | The queue number used for receiving filtered packets, default is nfqueue_num=0 |
- | interface | no | The interface used for sending the magic packet, default is interface=eth0 |
- | broadcast | no | Send magic packet to broadcast address, default is broadcast=off |
- | password | no | Set a password (required by some adapters), e.g. password=00:22:44:66:88:aa or 192.168.1.1 |
- | enabled | no | Optionally disable the target, default is enabled=true |
-
- After committing your changes, the settings are persisted to
- */etc/config/etherwake-nfqueue*. This is an illustrative example:
- ```
- config etherwake-nfqueue 'setup'
- option sudo 'off'
- option debug 'off'
-
- config target
- option name 'nas'
- option mac '00:25:90:00:d5:fd'
- option interface 'eth0.3'
-
- config target
- option name 'xyz-board'
- option mac '00:25:90:00:d5:fc'
- option nfqueue_num '1'
- option enabled 'false'
-
- config target
- option name 'ip-camera'
- option mac '00:25:90:00:d5:fb'
- option nfqueue_num '2'
- option interface 'eth0.3'
- option broadcast 'on'
- option password '00:25:90:00:d5:fb'
- ```
-
- When all target(s) are configured, restart the *etherwake-nfqueue* service:
- ```
- /etc/init.d/etherwake-nfqueue restart
- ```
-
- ### Setting up filters
-
- Without any firewall rules which tell the kernel to match and add packets
- to a *nfnetlink_queue*, **etherwake-nfqueue** will never send out a magic
- packet to wake its target.
-
- #### Prerequisites
-
- In order to let the *netfilter* framework of the kernel see the packets,
- they need to pass through the router. This is usually not the case when
- hosts are on the same subnet and don't require network layer routing.
- The data will only pass through the router's switch on the link layer.
-
- As a consequence, we can only use packets as a trigger which need to be
- routed or bridged by the router. Packets being forwarded between WAN
- and LAN are of that type. For other SOHO use cases, partitioning your
- network by means of subnets or VLANs might be necessary. The latter
- is often used to set up a DMZ.
-
- For VLANs:
-
- * There's a mini howto referring to the **LuCI Web Interface**
- *(Network -> Switch)* way of configuring VLANs:
- [How-To: Creating an additional virtual switch on a typical home router](https://openwrt.org/docs/guide-user/network/vlan/creating_virtual_switches)
-
- * The manual approach is documented here:
- [VLAN](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration)
-
- Guides to setup a DMZ can be found here:
-
- * [Guide to set up DMZ via LUCI](https://forum.openwrt.org/t/guide-to-set-up-dmz-via-luci/21616)
-
- * [fw3 DMZ Configuration Using VLANs](https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_dmz)
-
- The physical switch layout is device specific. E.g. the layout for the Linksys
- WRT AC Series is documented
- [here](https://oldwiki.archive.openwrt.org/toh/linksys/wrt_ac_series#switch_layout).
-
-
- Using two LANs or VLANs with the same network address and bridging them again
- is a trick to setup a transparent (or bridging) firewall on the same subnet.
- This way, packets can be seen by *netfilter* on the router even if the
- packets are not routed. Unfortunately this doesn't help when the host
- which we want to wake up is offline, as the ARP requests for the destination
- IP address are not answered and thus the client trying to reach out to its
- destination will not send any *network layer* packets. We could use *arptables*
- instead to wake the host when someone requests its MAC address, but this
- would probably happen too often and no fine-grained control would be possible.
-
- As a workaround, it might be possible to configure a static ARP entry on your
- router (untested), e.g. with:
- ```
- ip neigh add 192.168.0.10 lladdr 00:25:90:00:d5:fd nud permanent dev eth0.3
- ```
- Note that this requires the *ip-full* OpenWrt package to be installed.
-
- To make your firewall rules work with bridging, you need to install the
- *kmod-br-netfilter* package and add `net.bridge.bridge-nf-call-iptables=1`
- to */etc/sysctl.conf*.
-
-
- #### Setup firewall rules
-
- One way to setup custom firewall rules in OpenWrt is through its
- */etc/firewall.user* script. This file can also be edited by means of
- the **LuCI Web Interface** *(Network -> Firewall -> Custom Rules)*.
-
- The file is interpreted as a shell script, so we can simply use **iptables**
- to add our custom firewall rules.
-
- Notice the comment
- ```
- # Internal uci firewall chains are flushed and recreated on reload, so
- # put custom rules into the root chains e.g. INPUT or FORWARD or into the
- # special user chains, e.g. input_wan_rule or postrouting_lan_rule.
- ```
-
- Refer to [Packet flow](https://oldwiki.archive.openwrt.org/doc/uci/firewall#packet_flow)
- for usable chains. In the example below, the chains *forwarding_lan_rule* and
- *forwarding_wan_rule* are used. To inspect the rule sets of the different tables, one can
- use
-
- ```
- iptables --list # default is --table filter
- iptables --table nat --list
- iptables --table mangle --list
- iptables --table raw --list # requires kmod-ipt-raw
- ```
-
- The following is an example of what could be added to */etc/firewall.user*:
-
- ```
- iptables --insert forwarding_lan_rule\
- --protocol tcp --in-interface=br-lan --out-interface=eth0.3\
- --destination 192.168.0.10 --destination-port 445\
- --match conntrack --ctstate NEW\
- --match limit --limit 3/hour --limit-burst 1\
- --jump NFQUEUE --queue-num 0 --queue-bypass\
- --match comment --comment "Wake up NAS on LAN SMB"
- iptables --insert forwarding_lan_rule\
- --protocol tcp --in-interface=br-lan --out-interface=eth0.3\
- --destination 192.168.0.11 --match multiport --destination-ports 515,54921,631\
- --match conntrack --ctstate NEW\
- --match limit --limit 3/hour --limit-burst 1\
- --jump NFQUEUE --queue-num 0 --queue-bypass\
- --match comment --comment "Wake up NAS on print request"
- iptables --insert forwarding_lan_rule\
- --protocol udp --in-interface=br-lan --out-interface=eth0.3\
- --destination 192.168.0.11 --destination-port 161\
- --match conntrack --ctstate NEW\
- --match limit --limit 3/hour --limit-burst 1\
- --jump NFQUEUE --queue-num 0 --queue-bypass\
- --match comment --comment "Wake up NAS on print request"
- iptables --insert forwarding_wan_rule\
- --protocol tcp --in-interface=eth1.2 --out-interface=eth0.3\
- --destination 192.168.0.10 --destination-port 22\
- --match conntrack --ctstate NEW\
- --match limit --limit 3/hour --limit-burst 1\
- --jump NFQUEUE --queue-num 0 --queue-bypass\
- --match comment --comment "Wake up NAS on WAN SSH"
- ```
-
- In this example, packets are filtered based on the protocol, their input
- and output interfaces, their destination (IP address) and their destination
- port(s).
-
- The option `--match conntrack --ctstate NEW` only matches packets of a new
- connection and `--match limit --limit 3/hour --limit-burst 1` limits the
- amount of packets that are matched. The latter option roughly matches
- only one packet per 20 minutes. The intention here is to not be too intrusive
- and avoid sending a lot of magic packets.
-
- The `--jump NFQUEUE --queue-num 0` options tell the *netfilter*
- framework to enqueue a matching packet to the NFQUEUE number 0. In this
- example, all four rules send the matching packets into queue 0. The
- additional option `--queue-bypass` helps in the situation, when
- **etherwake-nfqueue** isn't running. Packets will then be handled
- as if the rule wasn't present.
-
-
- ## Disabling targets
-
- To disable targets, first find their index:
- ```
- uci show etherwake-nfqueue
- ```
-
- Then set its *enabled* option to false and restart the service.
- For index 0, it can be done like this:
- ```
- uci set etherwake-nfqueue.@target[0].enabled=false
- /etc/init.d/etherwake-nfqueue restart
- ```
-
-
- ## Troubleshooting
-
- ### Debug mode
-
- In order to see what's going on in syslog and get some debug output when
- starting the service, enable etherwake-nfqueue's debug mode:
- ```
- uci set etherwake-nfqueue.setup.debug=on
- ```
- In another user session tail the log:
- ```
- logread -f
- ```
- And then restart the service:
- ```
- /etc/init.d/etherwake-nfqueue restart
- ```
-
- ### Inspect netfilter
-
- To inspect the working of your firewall rules, you can print statistics
- of the chains you used, e.g.:
- ```
- iptables --verbose --list forwarding_lan_rule
- ```
-
- If you happen to have the *procps-ng-watch* package installed, you can watch
- them:
- ```
- watch iptables --verbose --list forwarding_lan_rule
- ```
-
- To see, if your queues are in place, use:
- ```
- cat /proc/net/netfilter/nfnetlink_queue
- ```
-
- ## Potential improvements
-
- * Add **LuCI Web Interface** configuration frontend for *targets* and *filter rules*
- * Add an option to set *nice* values for instances
|