This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

WOL over the Internet

I know this topic has been discussed in the past, however, in each case there has not been an actual detailed solution tabled, only alternative workarounds.

I am wanting to send a WOL packet via my Android smartphone to my home PC. I have the latest Astaro v8 free running on a dedicated machine. I can do this successfully for ~60 seconds after the machine is put to sleep but this then fails to work due to the ARP cache entry expiring. Astaro is setup with a DNAT forwarding port 9 to my PC as it seems that it will not transmit a broadcast via NAT.

There are a number of potential solutions to this problem:
1) Setup a static ARP entry
2) Setup bridging

I am not sure if #1 is possible with Astaro, does anyone know this?

#2 was suggested in a couple of the previous WOL discussions, however I am unsure of the theory of how this would work in conjunction with the existing NAT setup or the repercussions of doing so (in particular with respect to security). Is anyone able to enlighten me on the details of this particular setup?

Any info would be greatly appreciated.

Cheers,

Sam.

This thread was automatically locked due to age.

Parents

0 trollvottel over 12 years ago
You can remove that packet filter rule again, as I updated my post because it's not necessary and false anyway, sorry.

For debugging this, please do some tcpdump captures at your ASG (I assume eth0 is your WAN interface?):

For incoming WOL packets: 'tcpdump -i eth0 -n udp dst port 9'
For outgoing broadcasts: 'tcpdump -i eth1 -e -n udp dst port 9'

while sending the packet.

You should see the incoming packet to the WAN IP, then an outgoing packet as broadcast. The site sends multiple WOL packets (I counted 20!), so don't get confused.

Also please check that the ASG packetfilter.log does not contain dropped WOL packets: Best would be to open several SSH shells at the same time, two for the tcpdumps and one for 'tail -f /var/log/packetfilter.log | grep "dstport=\"9\""'.

This is how it looks like for me when it works:

asg120:/root # tcpdump -i eth1 -n udp dst port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:40:08.104322 IP 208.77.98.204.41308 > A.W.A.N.9: UDP, length 102
[19x...]

asg120:/root # tcpdump -i eth0 -n -e udp dst port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:36:36.346745 00:90:fb:33:22:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 144: 208.77.98.204.40967 > F.A.K.E.9: UDP, length 102
[19x...]

My Internal is eth0 and WAN is eth1, though.
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 trollvottel over 12 years ago
You can remove that packet filter rule again, as I updated my post because it's not necessary and false anyway, sorry.

For debugging this, please do some tcpdump captures at your ASG (I assume eth0 is your WAN interface?):

For incoming WOL packets: 'tcpdump -i eth0 -n udp dst port 9'
For outgoing broadcasts: 'tcpdump -i eth1 -e -n udp dst port 9'

while sending the packet.

You should see the incoming packet to the WAN IP, then an outgoing packet as broadcast. The site sends multiple WOL packets (I counted 20!), so don't get confused.

Also please check that the ASG packetfilter.log does not contain dropped WOL packets: Best would be to open several SSH shells at the same time, two for the tcpdumps and one for 'tail -f /var/log/packetfilter.log | grep "dstport=\"9\""'.

This is how it looks like for me when it works:

asg120:/root # tcpdump -i eth1 -n udp dst port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
09:40:08.104322 IP 208.77.98.204.41308 > A.W.A.N.9: UDP, length 102
[19x...]

asg120:/root # tcpdump -i eth0 -n -e udp dst port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:36:36.346745 00:90:fb:33:22:e7 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 144: 208.77.98.204.40967 > F.A.K.E.9: UDP, length 102
[19x...]

My Internal is eth0 and WAN is eth1, though.
Cancel
Vote Up 0 Vote Down

Cancel

Children

No Data