Problem with Wake on Lan

I have two Intel Atom 330 based PCs running FreeBSD 7.2. The motherboards have integrated networking and run fine with the re driver. I also have a Windows XP machine which is plugged into the same gigabit switch.

I can send a wake on lan request from the XP machine to either FreeBSD machines and they power up perfectly. My problem is trying to get them to wake using a FreeBSD box to send the magic packet. I've installed wakeonlan-0.41 and wol-0.7.1_1 from the ports tree. They both compile and execute, but I can't get either of them to power up my development FreeBSD box.

I ran tcpdump on one FreeBSD machine and could see the wol packet from my XP machine:
Code:
22:45:01.320577 IP amd64.home.2827 > 255.255.255.255.echo: UDP, length 102
Everything here works as it should. The magic packet comes from my XP computer and powers up either of the FreeBSD machines.

I've tried every option that wol or wakeonlan will accept and I have never seen the packet show up in tcpdump. For some reason it doesn't seem to want to broadcast. I added a broadcast option in /etc/rc.conf and rebooted but that did not seem to help. Here are the network settings from rc.conf:
Code:
ifconfig_re0="inet 192.168.1.53  netmask 255.255.0.0 broadcast 255.255.255.255"

Here is the re setting from ifconfig
Code:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:1c:c0:e0:a9:8c
        inet 192.168.1.53 netmask 0xffff0000 broadcast 255.255.255.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

Does anyone have any idea what could be the problem with this configuration? I'm going nuts trying to figure out why I don't see anything in tcpdump from wol and wakeonlan. I've searched the net many times but haven't been able to find any pages dealing with a similar problem.
 
Those network settings look wrong to me. Are you actually running a LAN from 192.168.0.0-192.168.255.255? Because that's what 'inet 192.168.1.53 netmask 255.255.0.0' is. And if you want to define a broadcast address within your network, it's actually 192.168.255.255 in this case, not 255.255.255.255. But first make sure you've actually defined the correct size for your network. Most people use a 256 IP network (255.255.255.0) for a LAN.
 
I just tried two different configurations with no success.

First:
Code:
rc.conf:
ifconfig_re0="inet 192.168.1.53  netmask 255.255.255.0"

ifconfig:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:1c:c0:e0:a9:8c
        inet 192.168.1.53 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

And the second:
Code:
rc.conf:
ifconfig_re0="inet 192.168.1.53  netmask 255.255.255.0 broadcast 192.168.255.255"

ifconfig:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
        ether 00:1c:c0:e0:a9:8c
        inet 192.168.1.53 netmask 0xffffff00 broadcast 192.168.255.255
        media: Ethernet autoselect (1000baseTX <full-duplex>)
        status: active

I knew that 255.255.255.255 wasn't the correct mask for my network but I was trying anything I could think of to see the broadcast on the other PC. I thought by using that netmask that it would eliminate an incorrect mask.
 
Well, you can try everything you like, but you should know what the correct size of your own network is ;)

Note that the broadcast address of a 192.168.1.53/255.255.255.0 network is 192.168.1.255, not 192.168.255.255.

I suggest you read up on CIDR (http://en.wikipedia.org/wiki/CIDR, http://en.wikipedia.org/wiki/CIDR_notation) and subnet masks (http://en.wikipedia.org/wiki/Subnetwork) and make sure you use the same network/netmask on all machines in your LAN.

BTW: you don't need to manually define a broadcast address. It's auto-calculated from your network/netmask combination.
 
This is the first time that I've ever used the broadcast setting in rc.conf. Like I said, I've been tweaking any parameter that I think could affect a broadcast. The first configuration from my previous message did have a broadcast mask of 255.255.1.255 and the packet never showed up on my machine running tcpdump. That's why I tried 192.168.255.255.

I'm really stumped as to why I don't see this broadcast packet. Do you know of any other applications which generate broadcast packets? I'd like to try narrow the problem down to see if it is a broadcast/network issue or an application issue.

Thanks for your help.
 
Sorry- I meant to say that my previous mask was 192.168.1.255. 255.255.1.255 was a typo.
 
Like I said: first make sure all of your machines in your LAN are in the same network and have the same subnet mask, or you'll be broadcasting into thin air.

Broadcasting stuff? ARP, the protocol by which machines in the same network find eachother. Try arp -a on the FreebSD machine. You should see the other hosts after pinging them. And if you run a tcpdump on your interface, you should see ARP requests and replies. IF they're all in the same network and in the correct subnet ..
 
All of the machines are 192.168.1.x and now have a netmask of 192.168.1.255. But even if the netmask was incorrect on the FreeBSD machine that is running tcpdump, shouldn't it still receive the broadcast packet?
 
I'm assuming you mean they're all in the 192.168.1.x network with a 255.255.255.0 netmask?

And no: different netmasks mean different broadcasts, that's what subnet masks are all about: keeping networks confined to their own playground. Overlapping networks with different netmasks should not be able to communicate (though they might, but with unpredictable results), and e.g. a network with a 192.168.255.255 broadcast address will not respond to 192.168.1.255 broadcasts. It's meaningless traffic.

Please read up on this stuff .. these are important fundamentals.
 
I ran arp -a when all of the machines were up and running- all of the entries were correct and all of the machines could communicate with each other without problems.

I am not a networking guru but I am familiar with the 7 layer model and how hardware addresses work on a lower level than IP. I would expect that I should be able to broadcast the magic packet with the host having no knowledge of the machine that the packet is intended for. I would need that functionality because the arp entries for the powered off machines will most likely expire before I need to send a wol packet.

What drives me nuts is that this work from my XP machine which has an ip address of 192.168.1.52 and a netmask of 255.255.255.0

And the netmask... I've been awake too long today. Yes, it is 255.255.255.0. It's been a long day.
 
Note that WOL functionality is defined by the motherboard and the NIC, and sometimes also controlled by the BIOS (I think I've seen BIOS options to turn WOL on/off). Make sure the hardware actually supports WOL and that it is enabled.

http://en.wikipedia.org/wiki/Wake-on-LAN
 
I can send the wol packet from the XP machine to either of the FreeBSD machines and they wake up perfectly. The problem I'm trying to solve is getting one of the FreeBSD machines to wake up the other. I'm positive that the hardware is working correctly.

I can't see the broadcast packet in tcpdump which is why the machine won't wake up. That's the problem that I'm trying to solve- why is the broadcast packet not being seen?
 
rob34 said:
I would need that functionality because the arp entries for the powered off machines will most likely expire before I need to send a wol packet.

That's exactly why I went on about the correct subnet mask. Only when the machines share the same broadcast address will the WOL packet be broadcast to the entire network, which is basically the same way ARP manages to 'resolve' all machines in a network.
 
Can't you see the WOL packet on the sending machine or on the receiving machine?
 
I can see the packet coming out of the FreeBSD machine which I use to run wol:
Code:
00:19:17.148970 IP dev.home.64399 > 255.255.255.255.echo: UDP, length 102

I am running tcpdump on the other FreeBSD machine and don't see the packet arrive. I'm also running Wireshark on the XP machine and can't see the packet there either.

When I send a wol packet from the XP machine I can see it being received on all 3 machines.
 
Well, I'm afraid you'll have to wait until someone who actually uses WOL in their network comes along, because a) I don't and b) it's 6:25 AM here and I need zzzzzz ;)

Final suggestion though: instruct the software to use either the IP address of the machine you're 'waking up', or to use the 192.168.1.255 broadcast address instead of 255.255.255.255. Just something I gleaned from wol(1) and wakeonlan(1). Good luck.
 
Thanks! I added a few lines to my previous post as an afterthought. See if that helps in any way.
 
Wake On LAN (WOL) / FreeBSD's WOL Port

I feel your frustration(s). I too went crazy with this for quite a while. (Not as much or as long as you two did...) I have come up with what MIGHT help/be your solution.

Thanks to both your inputs, I have had success. I'm using the ports WOL v0.7.1 - The syntax for the WOL port took me a little bit of (many) trial-and-errors, and I noted it uses by default port 40000 - you'll need to determine the port that your NIC listens to for WOL - here's what worked for me:

Code:
wol -v -p 9 --host=192.165.1.93 --ipaddr=192.168.1.255 00:22:68:39:0e:ce

RE: Someone who uses WOL?

Picture this; We have 1500+ workstations - that/where if they're powered off every night, then WOL could be utilized to make updates/patches/scans, then put the systems back into power-off mode...this is a considerable amount of energy savings. I would imagine the savings are in the thousands($)/month. (I'm a geek, not an accountant.) ;-)

Lastly - make SURE the BIOS on/in your system(s) allow you to send the "Magic Packets" to utilize WOL. My System had TWO settings in the BIOS to make it happen.

Note: WOL worked as my system was "powered-off." I can't imagine it wouldn't wake a "sleeping/hybernated" Windoze host.

Hope this helps/ed...(and anyone else coming across/searching this post to get more sleep than we did. :) )
 
BillFinkNC said:
I feel your frustration(s). I too went crazy with this for quite a while. (Not as much or as long as you two did...) I have come up with what MIGHT help/be your solution.

Thanks to both your inputs, I have had success. I'm using the ports WOL v0.7.1 - The syntax for the WOL port took me a little bit of (many) trial-and-errors, and I noted it uses by default port 40000 - you'll need to determine the port that your NIC listens to for WOL - here's what worked for me:

Code:
wol -v -p 9 --host=192.165.1.93 --ipaddr=192.168.1.255 00:22:68:39:0e:ce

RE: Someone who uses WOL?

Picture this; We have 1500+ workstations - that/where if they're powered off every night, then WOL could be utilized to make updates/patches/scans, then put the systems back into power-off mode...this is a considerable amount of energy savings. I would imagine the savings are in the thousands($)/month. (I'm a geek, not an accountant.) ;-)

Lastly - make SURE the BIOS on/in your system(s) allow you to send the "Magic Packets" to utilize WOL. My System had TWO settings in the BIOS to make it happen.

Note: WOL worked as my system was "powered-off." I can't imagine it wouldn't wake a "sleeping/hybernated" Windoze host.

Hope this helps/ed...(and anyone else coming across/searching this post to get more sleep than we did. :) )

This worked great, thank you!

One note though... I think you meant to have 192.168.1.93 instead of 192.165.1.93 in your example.
Code:
wol -v -p 9 --host=192.165.1.93 --ipaddr=192.168.1.255 00:22:68:39:0e:ce
 
Hi,
thanks a lot for these hints. I'm hopefully not confusing any readers with my non-native English.

I was using [cmd=]wakeonlan -f FILE[/cmd] on my former non-BSD machine to wake up my server with following FILE.

00:11:22:33:44:55

Doesn't work this way in FreeBSD.

The limited broadcast address (255.255.255.255) which is default in wakeonlan (and wol) doesn't work with my Class 1 C network. (Server@192.168.1.2 , client in the same Subnet@255.255.255.0)

If the -i option in wakeonlan/wol is specified with the broadcast address of this subnet (192.168.1.255) both programs fulfill their purpose.
So I've added the appropriate broadcast address to FILE:

00:11:22:33:44:55 192.168.1.255

Now both [cmd=]wol -f FILE[/cmd] and [cmd=]wakeonlan -f FILE[/cmd] are waking up my server.

As a matter of fact [cmd=]wol -v -i 192.168.1.255 00:11:22:33:44:55[/cmd] and [cmd=]wol -v -h 192.168.1.2 00:11:22:33:44:55[/cmd] also woke up my server.

If you specify the targeted host with the option -h (--host=) or the broadcast address with -i (--ip-addr=) the (inoperable?) limited broadcast address will be circumvented.
 
I've to correct my statement about the limited broadcast address (regarding to the last sentence in brackets).
255.255.255.255 should reach the addresses in the same subnet. But actually it doesn't. That's confusing me.

&quot said:
Limited broadcast. Can only be used as a destination
address, and a datagram with this address must never be
forwarded outside the (sub-)net of the source.
Further readings on Broadcast address. (see also RFC919)

I'm not sure how to determine, in which layer the packet to the limited broadcast address is lost.
It could be on the wakeonlan/wol layer or FreeBSD related, the managed hub in between doesn't see any transmitted broadcast packets when sent to 255.255.255.255.
I think the translation between 255.255.255.255 into a local broadcast might be wrecked, if limited broadcast should be permitted. If not, I'm happy with my new FILE layout.

Code:
{Hardware address1} {Broadcast or IP address}:{Port} {Password}  
{Hardware address2} {Broadcast or IP address} {Port}
# 1st line for wol-layout and 2nd for wakeonlan
@BillFinkNC: The FILE can hold several targets, each in a new line.

In my case the destination port doesn't play a role. It works with 40000 (wol default), 9 (wakeonlan default) and arbitrarily chosen ports 6 & 12345.
 
Back
Top