Help on error messages please

[to-scho]

Hi,

I did make, sudo make install and entered settings in /etc/wake-on-arp.conf. When I call sudo wake-on-arp I got error messages and do not know how to proceed.

Can you have a look please?

Regards, Tobias

pi@pi4:~ $ sudo cat /etc/wake-on-arp.conf
broadcast_ip  192.168.42.255
target_ip_1   192.168.42.200
target_mac_1  00:11:32:f7:87:ab
net_device    eth0
subnet        24
allow_gateway false 

pi@pi4:~ $ sudo wake-on-arp
Error in recieved packet: Success
Read From Socket Failed...

First error is due to NLMSG_OK(nlHdr, readLen) returning false.

[Falcosc]

Sounds like something in the netlink response is unexpected.

Check what ip route does say to your setup, it uses netlink as well.

Found this info here: https://olegkutkov.me/2019/03/24/getting-linux-routing-table-using-netlink/

[to-scho]

pi@pi4:~ $ ip route default via 192.168.42.1 dev eth0 src 192.168.42.149 metric 202 169.254.0.0/16 dev veth3c2f7bd scope link src 169.254.212.134 metric 207 169.254.0.0/16 dev veth74e446b scope link src 169.254.209.238 metric 213 169.254.0.0/16 dev veth218f5b3 scope link src 169.254.248.61 metric 215 169.254.0.0/16 dev vethc34c7e9 scope link src 169.254.246.91 metric 223 169.254.0.0/16 dev veth30ed2b1 scope link src 169.254.187.203 metric 225 169.254.0.0/16 dev veth4c2cdc8 scope link src 169.254.121.171 metric 121697 169.254.0.0/16 dev veth2789e4e scope link src 169.254.252.55 metric 122385 169.254.0.0/16 dev veth1ed2976 scope link src 169.254.173.197 metric 122387 169.254.0.0/16 dev veth0855377 scope link src 169.254.213.243 metric 122389 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.30.32.0/23 dev hassio proto kernel scope link src 172.30.32.1 192.168.42.0/24 dev eth0 proto dhcp scope link src 192.168.42.149 metric 202

[Falcosc]

Does not look unusual, my output is similar for eth0

pi@raspberrypi:~ $ ip route default via 192.168.1.1 dev eth0 src 192.168.1.10 metric 202 192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.10 metric 202

So, you have to wait for nikp123

I could only create a PR where the netlink code gets skipped if you would like to use allow_gateway true We did introduce the block gateway because many routers do send ARP requests for old known ips which results into unwanted wake ups

[to-scho]

What about a PR that skips the nettling code if gateway is specified in config file ;-)

[Falcosc]

Removing the netlink part has to be discussed with @nikp123 because this code is his favorite part of this project. I guess https://olegkutkov.me/2019/03/24/getting-linux-routing-table-using-netlink/ is a good source to get more familiar with netlink.

They do iterate over the valid headers, while (NLMSG_OK(h, msglen)) until a broken header stops the loop instead of printing an error if there is a single invalid header in your table like we do. Maybe you have a broken table entry.

[nikp123]

is his favorite part of the project. Nice...

I have no issue with skipping that code entirely if you specify the gateway yourself. The idea was that on DHCP the gateway changes, so you'd have to chase it, which is beyond annoying, which is why the netlink stuff is used. Anyway doing a bit of uni stuff atm, so stuff is slightly delayed. But that suggestion is just fine.

[nikp123]

that connection diagram leads me to believe that youre running that inside some firewall or a container. I honestly never designed this thing to work in such conditions, but am open for any fixes/features.

[to-scho]

nope, it's running purely on the raspberry pi os. On same pi I have containers running that show up additional interfaces.

[nikp123]

@to-scho i know this may be late, but try the new commit. It should show what's actually wrong. It was improper error message parsing that lead to that error, however not sure whether this code will crash as I wasn't able to reach it myself.

[nikp123]

oh nevermind, it's not that it seems. didnt read from the beginning, sorry..

[nikp123]

though this is pretty interesting

[nikp123]

https://gist.github.com/utky/de8b37756f8664d0045f829292657ae5#gistcomment-3878697

[nikp123]

that thing is even goofier

[to-scho]

In NLMSG_OK(nlHdr, readLen) readLen is 0 which looks suspicious to me.