Wake-on-wan (good enough, but could be better)

Stock Zyxel firmware has a wake-on-wan feature if I recall correctly. I don't recall how that setup worked but here's how to achieve similar functionality via openwrt.

! It does feel 'hacky' and not super clean either (all udp on port 9 gets mapped to the broadcast)
but until i find a better solution this will have to do.

under network>firewall>port forwards add a redirect rule
upd port 9 form wan to a 'will-never-be-used' local ip address, e.g. 10.0.0.253
then, from the CLI map this addr to the broadcast mac addr,
 ip neigh add 10.0.0.253 lladdr ff:ff:ff:ff:ff:ff nud permanent dev br-lan
You're done! ... but not quite.
there are some pitfalls.


  1. the arp table can get flushed, e.g. interface changes, or reboot. You can add this line to rc.local, or as an init.d script or i supposes a procd script... but no info on what is best, hopefully more soon.
  2. the magic incantation above can fail of the ip is already known. I haven't found a clean way to flush an addr from the arp table so if you tested the forward rule it will show up in the arp table - but you wont't be able to set it to the broadcast. 
Error: either "to" is duplicate, or "lladr" is a garbage.
  I first tried with ...254, which still shows up in my arp table ...
10.0.0.254 0x1 0x0 00:00:00:00:00:00 * br-lan

all in all, not too happy with this situation... there ought to be a better way.

Comments

Post a Comment

Popular posts from this blog

Traffic accounting

Got this from here: http://www.catonmat.net/blog/traffic-accounting-with-iptables/ All i'm interested in is my monthly bandwidth consumption, not the individual devices, there are plenty of forum threads/tools to do that. But why bring in additional tools when iptables has it all? iptables -N TRAFFIC_ACCT iptables -I FORWARD -j TRAFFIC_ACCT iptables -A TRAFFIC_ACCT and to just get the number: iptables -L TRAFFIC_ACCT -v | sed -n 3p | cut -d' ' -f2 to reset the counters /usr/sbin/iptables -L TRAFFIC_ACCT -Z the cron job to reset at the begining of the month, and a daily telegram msg 1 0 1 * * /usr/sbin/iptables -L TRAFFIC_ACCT -Z  0 8 * * * /usr/bin/curl -s -X POST https://api.telegram.org/<BOTID>/sendMessage -d chat_id=<CHATID> -d text="$(/usr/sbin/iptables -L TRAFFIC_ACCT -v | /bin/sed -n 3p | /usr/bin/cut -d' ' -f3)" >/dev/null 2>&1 (you'll need to opkg install ca-bundle for the https to work)
Read more

QoS with SQM (and something about bufferbloat)

another feature that came with stock zyxel fw is their 'optimized' (the one with the 400mbps nag) QoS packages. As far as i can tell the standard SQM package should come pretty close. install uci-app-sqm a Network>SQM QoS menu item will appear check enable, double check your interface name is really your wan port(eth1), and set your down/up speeds to what you measured with e.g. dslreports . under linklayer adaptation set to Ethernet (for VDSL) with 8 bytes overhead. i reran the test, and it seems my up/down throughput dropped about 10%,  but my bufferbloat report went from D to B.... whatever that means in reality I'll have to find out :)
Read more

Ath10k alternative driver firmware - CC15.05.1 wireless unstable

I'm still experiencing trouble with the 5Ghz, maybe even WRT in general, up to the point I'm considering going back to the original Zyzel AA release. One last effort to see if this helps: I'm currently running an alternative driver firmware for the  QCA988X get it from github i'm running the last of the 4 series 10.2.4.48 (not sure if running the 5 series is possible, something for later) rename the file to firmware-4.bin and replace the one that's already there in /lib/firmware/ath10k/QCA988X/hw2.0 There's probably a way to force WRT to reload the driver, but hey I rebooted. First look seems fine, let's see if it's more stable. -- update -- leaving channel selection on 'auto' didn't work - 5G did not come up. (no mesgs as to why) manually selecting a channel did seem to work, at least when also selecting a 20Mhz bandwidth, 40Mhz seemed to work but I had some devices not connecting properly. -- update2 -- 5G was mostly s...
Read more