Malformed wol packets
-
@JKnott
Oops should have said or as per the wireshark capture filter:-ether proto 0x0842 or udp port 9
-
The point is not that I get malformed packages in Wireshark, the point is that I can't wake up my PC with the the pfSense WOL feature. It works with (almost) every random WOL app on my phone, tablet and laptop (which obviously sends some different kind of package than pfSense does). So this is definitely a pfSense problem.
-
What happens with the wol command at the command prompt?
-
@JKnott
When I issue "wol -i 192.168.5.255 40:8d:5c:56:e1:24" on my pfsense box I get the exact same packet as shown in my first post. -
@JKnott
Also, when I issue the "wakeonlan 40:8d:5c:56:e1:24" command on a debian machine I get the following correct packet in wireshark which actually wakes up my PC.
-
Why are you including the broadcast IP address with the MAC? Whenever I used WoL, I just sent the MAC address. Here's the script I used to wake up a Netfinity server, which I just took to recycling this week.
/usr/bin/wol 00:02:55:47:E0:7BBTW, I see you're using display filters in Wireshark, rather than capture filters. You may want to learn about capture filters, as they capture only the traffic of interest, where as display filters are used to select packets from what has been captured. If you don't use capture filters, you capture everything. I rarely use display filters, though I do have one to hide any packets containing the MAC of the computer I'm running Wireshark on. I do that to reduce the clutter.
-
i have no issues using WOL with my pfsense.
i have wol working for multiple PCs over LAN and WAN. -
I haven't said anything so far, but wol work for me too on my pcs, sometimes i turn on my smart tv with that, the only thing that i'm unable to turn on with wol are virtual machine inside esxi. but that is another matter ..i have yet to investigate
-
@JKnott
that was just for testing purpose, usually I use the pfSense Webinterface (Services -> Wake-on-Lan) to issue the command but that leads to the same result.
I'm just wondering why my Windows Machine won't turn on when I send the WoL command from the pfSense box when it seems to work for everyone else here.
Also sending it from any other system/device in my network works fine for me (tested with my laptop and android phone). Everything but pfSense seems to be able to turn on my pc via WoL.Also ty for the info, def. looking into capture filters :)
-
@AceFloof said in Malformed wol packets:
@JKnott
Also, when I issue the "wakeonlan 40:8d:5c:56:e1:24" command on a debian machine I get the following correct packet in wireshark which actually wakes up my PC.
Hello @AceFloof ,
After trying to find what was 'knx/ip unknown service family' I was redirected to your post.
Currently I'm using pfSense 2.5.0-devel and I have the same problem as you, as you can see:
All other devices and applications sends the correct magic packet on the port 9, pfSense sends it on port 40000.
I have sent WOL packets from pfSense to Windows 10 and Manjaro Linux hosts, and none of them will wake up.
I have APs from Unifi and Netgear switches on my Network, among other IOT stuff, and also VLANs.
I'm trying to understand what we have in common, and if you solved the issue?
-
I just went over this not that long ago that pfsense sends out on 40k..
https://forum.netgate.com/post/912917
That you don't know how to use wireshark, doesn't mean the packet is malformed ;)
I can tell wireshark anything is what its not and its going to show up as messed up...
the correct magic packet on the port 9, pfSense sends it on port 40000.
Where did you come up with the idea that port 9 is the correct port? Port means NOTHING in a wol packet.. what port it gets sent out in doesn't mean anything.. Sure there are some common ports 0, 7, 9 etc.. 0 is just going to be a security nightmare and wouldn't normally be allowed out from a firewall at all.. 7 and 9 have their own issues because old clients could see those since its sent to broadcast address, etc.
Sure wireshark will see udp on 9 and think oh wol, and then decode it for that.. But again - what wireshark does for dissection of any given packet is ultimately up to the user using it.. If you say a packet is WOL and its NOT then it will show malformed, if you say its X when its Y, again malformed.. Wireshark tries and make a guess to what the data is - it quite often makes mistakes.. For example thinking your wol is knx..
First thing that jumps out at me looking at that sniff - is wtf, they using a /15 mask?? WHY??? Your broadcast is 172.19.255.255 and your coming from a 172.18.0.12 - that is a /15.. Why would you be using that??? My guess why something isn't working is you prob have issues with your mask on your devices..
-
@johnpoz said in Malformed wol packets:
I just went over this not that long ago that pfsense sends out on 40k..
https://forum.netgate.com/post/912917
That you don't know how to use wireshark, doesn't mean the packet is malformed ;)
I can tell wireshark anything is what its not and its going to show up as messed up...
the correct magic packet on the port 9, pfSense sends it on port 40000.
Where did you come up with the idea that port 9 is the correct port? Port means NOTHING in a wol packet.. what port it gets sent out in doesn't mean anything.. Sure there are some common ports 0, 7, 9 etc.. 0 is just going to be a security nightmare and wouldn't normally be allowed out from a firewall at all.. 7 and 9 have their own issues because old clients could see those since its sent to broadcast address, etc.
Sure wireshark will see udp on 9 and think oh wol, and then decode it for that.. But again - what wireshark does for dissection of any given packet is ultimately up to the user using it.. If you say a packet is WOL and its NOT then it will show malformed, if you say its X when its Y, again malformed.. Wireshark tries and make a guess to what the data is - it quite often makes mistakes.. For example thinking your wol is knx..
Why on ports 7 and 9 it sees as a correct wol type packet, and it sees wol on packet 40000 ? How me as a user can affect Wireshark dissection? I just listen on my device for any wol packets, sent by pfSense or other applications. The only one that is perceived as malformed is one sent by wake on lan client on pfSense. If this is a wireshark issue, then sure, glad that I learned about it from this thread. As a user you interpret the Wireshark response, and as I refused to believe the application, I have searched the Internet, and found this thread.
Anyways the issue is still present at this time.First thing that jumps out at me looking at that sniff - is wtf, they using a /15 mask?? WHY??? Your broadcast is 172.19.255.255 and your coming from a 172.18.0.12 - that is a /15.. Why would you be using that??? My guess why something isn't working is you prob have issues with your mask on your devices..
I don't understand what is your concern here...
From here:
https://www.ietf.org/rfc/rfc1918.txtand here:
http://jodies.de/ipcalc?host=172.18.0.12&mask1=15&mask2=
I use Private Address Space as seen above. Also I can do subnetting or play with the range as it suits my needs.
@johnpoz said in Malformed wol packets:
A /15 makes zero sense to be assigned to any device... Do you have something close to 130K devices on this network? Really? Use something realistic.. How many devices do you have on this network? How many might it grow too?
Such a mask is something you might use on a route summary, or firewall rule with a bunch of downstream networks.. Not anything you would ever use on a single L2..
I read through some of your posts on this forum, and I know you always try to help, and I appreciate your input(really) but in my case I am respecting the standards. Asking someone to re-shape his network for no reason, it's not helpful, sorry to say this.
-
A /15 makes zero sense to be assigned to any device... Do you have something close to 130K devices on this network? Really? Use something realistic.. How many devices do you have on this network? How many might it grow too?
Such a mask is something you might use on a route summary, or firewall rule with a bunch of downstream networks.. Not anything you would ever use on a single L2..
