You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

378 lines
14 KiB

  1. # OpenWrt package feed for etherwake-nfqueue
  2. ## Wake up computers on netfilter match
  3. This repository contains the OpenWrt package feed for
  4. [etherwake-nfqueue](https://github.com/mister-benjamin/etherwake-nfqueue),
  5. a fork of the **etherwake** Wake-on-LAN client, with support to send magic
  6. packets only after a queued packet is received from the Linux *nfnetlink_queue*
  7. subsystem.
  8. When running **etherwake-nfqueue** on a residential gateway or other type of
  9. router, it can wake up hosts on its network based on packet filtering rules.
  10. For instance, when your set-top box wants to record a TV programme and
  11. tries to access a network share on your NAS, which is in sleep or standby mode,
  12. **etherwake-nfqueue** can wake up your NAS. Or when you set up port forwarding
  13. to a host on your home network, **etherwake-nfqueue** can wake up your host
  14. when you try to access it over the Internet.
  15. The documentation below is mostly OpenWrt specific. For more information on
  16. etherwake-nfqueue itself and use case examples, please consult its
  17. [Readme](https://github.com/mister-benjamin/etherwake-nfqueue/blob/master/README.md).
  18. ## Building the package
  19. Currently, no pre-built packages are provided. The following assumes that you
  20. already have a working OpenWrt build system for your target device.
  21. If you haven't, you can follow one of these guides:
  22. * If you only want to compile packages, and no firmware image:
  23. [Build system – Installation](https://openwrt.org/docs/guide-developer/build-system/install-buildsystem) and
  24. [Using the SDK](https://openwrt.org/docs/guide-developer/using_the_sdk)
  25. * To quickly build a firmware image off a development snapshot:
  26. [Quick Image Building Guide](https://openwrt.org/docs/guide-developer/quickstart-build-images)
  27. * Or when you are completely new to using build systems:
  28. [Beginners guide to building your own firmware](https://openwrt.org/docs/guide-user/additional-software/beginners-build-guide)
  29. ### Dependencies
  30. **etherwake-nfqueue** depends on these OpenWrt packages:
  31. * libnetfilter-queue
  32. * iptables-mod-nfqueue
  33. They will be automatically selected and compiled for you. If they are not
  34. installed on your target device, *opkg* will try to resolve dependencies with
  35. packages in the repositories.
  36. ### Adding the package feed
  37. First, you need to add the **etherwake-nfqueue** package feed to your build
  38. system. In the root directory of your OpenWrt build system, find the file
  39. *feeds.conf* (or *feeds.conf.default* if the former shouldn't exist) and add
  40. the following line to it:
  41. ```
  42. src-git ethernfq https://github.com/mister-benjamin/etherwake-nfqueue-openwrt.git
  43. ```
  44. Then update and install the package feed:
  45. ```
  46. user@host:~/openwrt$ scripts/feeds update ethernfq
  47. user@host:~/openwrt$ scripts/feeds install -a -p ethernfq
  48. ```
  49. After that, enter OpenWrt's configuration menu
  50. ```
  51. user@host:~/openwrt$ make menuconfig
  52. ```
  53. and enable **etherwake-nfqueue** in the **Network** sub-menu. It can either be selected
  54. as built-in (\*) or module (M), depending on your decision to include it into a
  55. firmware image or just build the *opkg* package for installation.
  56. Then you should be able to compile the package:
  57. ```
  58. user@host:~/openwrt$ make package/etherwake-nfqueue/compile
  59. ```
  60. The path of the resulting package depends on your selected *Target System*.
  61. In case of the Linksys WRT1200AC, it can be found here:
  62. ```
  63. bin/packages/arm_cortex-a9_vfpv3/ethernfq/etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk
  64. ```
  65. ## Installation
  66. One way to install the package is by simply copying it over to the device with *scp*:
  67. ```
  68. user@host:~$ scp etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk root@gateway:~
  69. ```
  70. And then, install it on the device:
  71. ```
  72. root@gateway:~# opkg install etherwake-nfqueue_2019-09-10-67e9d4ca-1_arm_cortex-a9_vfpv3.ipk
  73. ```
  74. ## Configuration
  75. ### WoL Targets
  76. After a fresh installation, no target is configured. Targets are referred
  77. to as the hosts to wake up. Multiple targets can coexist.
  78. Targets can be configured with OpenWrt's UCI.
  79. For example, to add a target called **nas**, with MAC address
  80. **00:25:90:00:d5:fd**, which is reachable over the VLAN configured
  81. on **eth0.3**, issue this command sequence on your router:
  82. ```
  83. uci add etherwake-nfqueue target
  84. uci set etherwake-nfqueue.@target[-1].name=nas
  85. uci set etherwake-nfqueue.@target[-1].mac=00:25:90:00:d5:fd
  86. uci set etherwake-nfqueue.@target[-1].interface=eth0.3
  87. uci commit
  88. ```
  89. For each target, one instance of **etherwake-nfqueue** will be started.
  90. Each instance should bind to a different *nfnetlink_queue*. A queue can
  91. be referenced by its queue number. Counting starts from 0, which is the default.
  92. To use a different queue, provide the **nfqueue_num** option. The
  93. following could have been added to the sequence above to use queue 1 instead
  94. of 0:
  95. ```
  96. uci set etherwake-nfqueue.@target[-1].nfqueue_num=1
  97. ```
  98. The necessity of a queue number will probably become clear, when the iptables
  99. rules are configured in section [Setup firewall rules](#setup-firewall-rules).
  100. The full list of options for a target is:
  101. | Option | Required | Description |
  102. | ----------- | -------- | ------------------------------------------------ |
  103. | name | no | Name of the target, e.g. name=example |
  104. | mac | yes | MAC address of the host to wake up, e.g. mac=00:22:44:66:88:aa |
  105. | nfqueue_num | no | The queue number used for receiving filtered packets, default is nfqueue_num=0 |
  106. | interface | no | The interface used for sending the magic packet, default is interface=eth0 |
  107. | broadcast | no | Send magic packet to broadcast address, default is broadcast=off |
  108. | password | no | Set a password (required by some adapters), e.g. password=00:22:44:66:88:aa or 192.168.1.1 |
  109. | enabled | no | Optionally disable the target, default is enabled=true |
  110. After committing your changes, the settings are persisted to
  111. */etc/config/etherwake-nfqueue*. This is an illustrative example:
  112. ```
  113. config etherwake-nfqueue 'setup'
  114. option sudo 'off'
  115. option debug 'off'
  116. config target
  117. option name 'nas'
  118. option mac '00:25:90:00:d5:fd'
  119. option interface 'eth0.3'
  120. config target
  121. option name 'xyz-board'
  122. option mac '00:25:90:00:d5:fc'
  123. option nfqueue_num '1'
  124. option enabled 'false'
  125. config target
  126. option name 'ip-camera'
  127. option mac '00:25:90:00:d5:fb'
  128. option nfqueue_num '2'
  129. option interface 'eth0.3'
  130. option broadcast 'on'
  131. option password '00:25:90:00:d5:fb'
  132. ```
  133. When all target(s) are configured, restart the *etherwake-nfqueue* service:
  134. ```
  135. /etc/init.d/etherwake-nfqueue restart
  136. ```
  137. ### Setting up filters
  138. Without any firewall rules which tell the kernel to match and add packets
  139. to a *nfnetlink_queue*, **etherwake-nfqueue** will never send out a magic
  140. packet to wake its target.
  141. #### Prerequisites
  142. In order to let the *netfilter* framework of the kernel see the packets,
  143. they need to pass through the router. This is usually not the case when
  144. hosts are on the same subnet and don't require network layer routing.
  145. The data will only pass through the router's switch on the link layer.
  146. As a consequence, we can only use packets as a trigger which need to be
  147. routed or bridged by the router. Packets being forwarded between WAN
  148. and LAN are of that type. For other SOHO use cases, partitioning your
  149. network by means of subnets or VLANs might be necessary. The latter
  150. is often used to set up a DMZ.
  151. For VLANs:
  152. * There's a mini howto referring to the **LuCI Web Interface**
  153. *(Network -> Switch)* way of configuring VLANs:
  154. [How-To: Creating an additional virtual switch on a typical home router](https://openwrt.org/docs/guide-user/network/vlan/creating_virtual_switches)
  155. * The manual approach is documented here:
  156. [VLAN](https://openwrt.org/docs/guide-user/network/vlan/switch_configuration)
  157. Guides to setup a DMZ can be found here:
  158. * [Guide to set up DMZ via LUCI](https://forum.openwrt.org/t/guide-to-set-up-dmz-via-luci/21616)
  159. * [fw3 DMZ Configuration Using VLANs](https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_dmz)
  160. The physical switch layout is device specific. E.g. the layout for the Linksys
  161. WRT AC Series is documented
  162. [here](https://oldwiki.archive.openwrt.org/toh/linksys/wrt_ac_series#switch_layout).
  163. Using two LANs or VLANs with the same network address and bridging them again
  164. is a trick to setup a transparent (or bridging) firewall on the same subnet.
  165. This way, packets can be seen by *netfilter* on the router even if the
  166. packets are not routed. Unfortunately this doesn't help when the host
  167. which we want to wake up is offline, as the ARP requests for the destination
  168. IP address are not answered and thus the client trying to reach out to its
  169. destination will not send any *network layer* packets. We could use *arptables*
  170. instead to wake the host when someone requests its MAC address, but this
  171. would probably happen too often and no fine-grained control would be possible.
  172. As a workaround, it might be possible to configure a static ARP entry on your
  173. router (untested), e.g. with:
  174. ```
  175. ip neigh add 192.168.0.10 lladdr 00:25:90:00:d5:fd nud permanent dev eth0.3
  176. ```
  177. Note that this requires the *ip-full* OpenWrt package to be installed.
  178. To make your firewall rules work with bridging, you need to install the
  179. *kmod-br-netfilter* package and add `net.bridge.bridge-nf-call-iptables=1`
  180. to */etc/sysctl.conf*.
  181. #### Setup firewall rules
  182. One way to setup custom firewall rules in OpenWrt is through its
  183. */etc/firewall.user* script. This file can also be edited by means of
  184. the **LuCI Web Interface** *(Network -> Firewall -> Custom Rules)*.
  185. The file is interpreted as a shell script, so we can simply use **iptables**
  186. to add our custom firewall rules.
  187. Notice the comment
  188. ```
  189. # Internal uci firewall chains are flushed and recreated on reload, so
  190. # put custom rules into the root chains e.g. INPUT or FORWARD or into the
  191. # special user chains, e.g. input_wan_rule or postrouting_lan_rule.
  192. ```
  193. Refer to [Packet flow](https://oldwiki.archive.openwrt.org/doc/uci/firewall#packet_flow)
  194. for usable chains. In the example below, the chains *forwarding_lan_rule* and
  195. *forwarding_wan_rule* are used. To inspect the rule sets of the different tables, one can
  196. use
  197. ```
  198. iptables --list # default is --table filter
  199. iptables --table nat --list
  200. iptables --table mangle --list
  201. iptables --table raw --list # requires kmod-ipt-raw
  202. ```
  203. The following is an example of what could be added to */etc/firewall.user*:
  204. ```
  205. iptables --insert forwarding_lan_rule\
  206. --protocol tcp --in-interface=br-lan --out-interface=eth0.3\
  207. --destination 192.168.0.10 --destination-port 445\
  208. --match conntrack --ctstate NEW\
  209. --match limit --limit 3/hour --limit-burst 1\
  210. --jump NFQUEUE --queue-num 0 --queue-bypass\
  211. --match comment --comment "Wake up NAS on LAN SMB"
  212. iptables --insert forwarding_lan_rule\
  213. --protocol tcp --in-interface=br-lan --out-interface=eth0.3\
  214. --destination 192.168.0.11 --match multiport --destination-ports 515,54921,631\
  215. --match conntrack --ctstate NEW\
  216. --match limit --limit 3/hour --limit-burst 1\
  217. --jump NFQUEUE --queue-num 0 --queue-bypass\
  218. --match comment --comment "Wake up NAS on print request"
  219. iptables --insert forwarding_lan_rule\
  220. --protocol udp --in-interface=br-lan --out-interface=eth0.3\
  221. --destination 192.168.0.11 --destination-port 161\
  222. --match conntrack --ctstate NEW\
  223. --match limit --limit 3/hour --limit-burst 1\
  224. --jump NFQUEUE --queue-num 0 --queue-bypass\
  225. --match comment --comment "Wake up NAS on print request"
  226. iptables --insert forwarding_wan_rule\
  227. --protocol tcp --in-interface=eth1.2 --out-interface=eth0.3\
  228. --destination 192.168.0.10 --destination-port 22\
  229. --match conntrack --ctstate NEW\
  230. --match limit --limit 3/hour --limit-burst 1\
  231. --jump NFQUEUE --queue-num 0 --queue-bypass\
  232. --match comment --comment "Wake up NAS on WAN SSH"
  233. ```
  234. In this example, packets are filtered based on the protocol, their input
  235. and output interfaces, their destination (IP address) and their destination
  236. port(s).
  237. The option `--match conntrack --ctstate NEW` only matches packets of a new
  238. connection and `--match limit --limit 3/hour --limit-burst 1` limits the
  239. amount of packets that are matched. The latter option roughly matches
  240. only one packet per 20 minutes. The intention here is to not be too intrusive
  241. and avoid sending a lot of magic packets.
  242. The `--jump NFQUEUE --queue-num 0` options tell the *netfilter*
  243. framework to enqueue a matching packet to the NFQUEUE number 0. In this
  244. example, all four rules send the matching packets into queue 0. The
  245. additional option `--queue-bypass` helps in the situation, when
  246. **etherwake-nfqueue** isn't running. Packets will then be handled
  247. as if the rule wasn't present.
  248. ## Disabling targets
  249. To disable targets, first find their index:
  250. ```
  251. uci show etherwake-nfqueue
  252. ```
  253. Then set its *enabled* option to false and restart the service.
  254. For index 0, it can be done like this:
  255. ```
  256. uci set etherwake-nfqueue.@target[0].enabled=false
  257. /etc/init.d/etherwake-nfqueue restart
  258. ```
  259. ## Troubleshooting
  260. ### Debug mode
  261. In order to see what's going on in syslog and get some debug output when
  262. starting the service, enable etherwake-nfqueue's debug mode:
  263. ```
  264. uci set etherwake-nfqueue.setup.debug=on
  265. ```
  266. In another user session tail the log:
  267. ```
  268. logread -f
  269. ```
  270. And then restart the service:
  271. ```
  272. /etc/init.d/etherwake-nfqueue restart
  273. ```
  274. ### Inspect netfilter
  275. To inspect the working of your firewall rules, you can print statistics
  276. of the chains you used, e.g.:
  277. ```
  278. iptables --verbose --list forwarding_lan_rule
  279. ```
  280. If you happen to have the *procps-ng-watch* package installed, you can watch
  281. them:
  282. ```
  283. watch iptables --verbose --list forwarding_lan_rule
  284. ```
  285. To see, if your queues are in place, use:
  286. ```
  287. cat /proc/net/netfilter/nfnetlink_queue
  288. ```
  289. ## Potential improvements
  290. * Add **LuCI Web Interface** configuration frontend for *targets* and *filter rules*
  291. * Add an option to set *nice* values for instances