WOL with msk(4) driver

Z

Zucca

Hello guys,

I have only about one month experience with this operating system but after 10 hours of no success this is my last card to play. I'm trying to wake up my FreeBSD box using the WOL method. My network works since I am waking up a Windows box (on the same subnet IP) and by using the same method with the right FreeBSD NIC MAC address it doesn't work.

I found no documentation regarding the TCP/IP port used by FreeBSD to receive the WOL Magic Packet, and I'm assuming it is 9/UDP.

The BIOS is also set correctly because in the past I was able to wake up a Windows system installed on that motherboard.

My suspect is that the FreeBSD NIC driver is not set properly. Here below the details of my network configuration.

ifconfig -m
Code: 
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        capabilities=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        ether 20:cf:30:4c:39:da
        inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255
        inet6 fe80::22cf:30ff:fe4c:39da%msk0 prefixlen 64 scopeid 0x1
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex,flowcontrol,rxpause,txpause>)
        status: active
        supported media:
                media autoselect mediaopt flowcontrol
                media autoselect
                media 1000baseT mediaopt full-duplex,master
                media 1000baseT mediaopt full-duplex
                media 1000baseT mediaopt master
                media 1000baseT
                media 100baseTX mediaopt full-duplex
                media 100baseTX
                media 10baseT/UTP mediaopt full-duplex
                media 10baseT/UTP
                media none
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        capabilities=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0xa
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Sure enough there is no WOL options activated for msk0. By using sysctl dev.msk.0.wake=1 I got this:

Code: 
sysctl: unknown oid 'dev.msk.0.wake'

Here further information with sysctl -a | grep msk

Code: 
device  msk
dev.mskc.0.%desc: Marvell Yukon 88E8059 Gigabit Ethernet
dev.mskc.0.%driver: mskc
dev.mskc.0.%location: slot=0 function=0
dev.mskc.0.%pnpinfo: vendor=0x11ab device=0x4381 subvendor=0x1043 subdevice=0x8439 class=0x020000
dev.mskc.0.%parent: pci3
dev.mskc.0.process_limit: 256
dev.mskc.0.int_holdoff: 100
dev.msk.0.%desc: Marvell Technology Group Ltd. Yukon Optima Id 0xbc Rev 0x01
dev.msk.0.%driver: msk
dev.msk.0.%parent: mskc0
dev.msk.0.stats.rx.ucast_frames: 797
dev.msk.0.stats.rx.bcast_frames: 125
dev.msk.0.stats.rx.pause_frames: 0
dev.msk.0.stats.rx.mcast_frames: 0
dev.msk.0.stats.rx.crc_errs: 0
dev.msk.0.stats.rx.good_octets: 89430
dev.msk.0.stats.rx.bad_octets: 0
dev.msk.0.stats.rx.frames_64: 392
dev.msk.0.stats.rx.frames_65_127: 449
dev.msk.0.stats.rx.frames_128_255: 77
dev.msk.0.stats.rx.frames_256_511: 2
dev.msk.0.stats.rx.frames_512_1023: 4
dev.msk.0.stats.rx.frames_1024_1518: 0
dev.msk.0.stats.rx.frames_1519_max: 0
dev.msk.0.stats.rx.frames_too_long: 0
dev.msk.0.stats.rx.jabbers: 0
dev.msk.0.stats.rx.overflows: 0
dev.msk.0.stats.tx.ucast_frames: 867
dev.msk.0.stats.tx.bcast_frames: 2
dev.msk.0.stats.tx.pause_frames: 0
dev.msk.0.stats.tx.mcast_frames: 0
dev.msk.0.stats.tx.octets: 108927
dev.msk.0.stats.tx.frames_64: 85
dev.msk.0.stats.tx.frames_65_127: 619
dev.msk.0.stats.tx.frames_128_255: 159
dev.msk.0.stats.tx.frames_256_511: 6
dev.msk.0.stats.tx.frames_512_1023: 6
dev.msk.0.stats.tx.frames_1024_1518: 2
dev.msk.0.stats.tx.frames_1519_max: 0
dev.msk.0.stats.tx.colls: 0
dev.msk.0.stats.tx.late_colls: 0
dev.msk.0.stats.tx.excess_colls: 0
dev.msk.0.stats.tx.multi_colls: 0
dev.msk.0.stats.tx.single_colls: 0
dev.msk.0.stats.tx.underflows: 0
dev.miibus.0.%parent: msk0

Also the command ifconfig msk0 wol don´t change the situation. According to ifconfig(8)
Enable Wake On Lan (WOL) support, if available.
Click to expand...
I think I´m in the case where WOL is not available.

Before I start to somehow patch the driver msk(4) and to compile the FreeBSD Kernel for the first time in my life, can you advise me if this is the right thing to do?

I´m running a ZFS only FreeBSD with 4K aligned SSDs in mirror configuration, and this is my uname -a

Code: 
FreeBSD chacho.com 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:            10 UTC 2012     root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64

Thanks in advance.
 
All right, if after 5 days here there are 0 replies it means it is 99,9% a driver or hardware related issue. Apparently there are no networking command or configuration which can resolve the situation. Now my 10 hours wasted hunting the right command start to make sense.

To Administrator: Please consider to move this thread in the "System Hardware" section, I will try to follow up this issue there with the driver developer.

Thanks.
 
It looks like your NIC doesn't support WOL.
Code: 
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
        capabilities=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
<snip>

Please, read support documentation: https://wiki.freebsd.org/WakeOnLan.
 
Only in case your Plan A (modifying the msk(4)() driver) doesn't work out, here come suggestions for Plans B and C.

Plan B: In the case your box got a free PCI-Slot, you could plug-in a very cheap (perhaps US$ 5) commodity 100Mbit/s NIC and connect it into your network for WOL only, for this you don't need to give it any IP. I know from experience that the re(4)() and vr(4)() drivers support WOL. In this scenario you would maintain your Marvell Yukon 88E8059 Gigabit Ethernet for network communication.

Plan C: Replace your present ethernet NIC with another Gigabit NIC, that supports WOL. This is a little bit more expensive, but you may want to look out for special offers. For example, recently I bought a Intel PRO/1000 MT Dual Port Server NIC for only US$ 40 here in Brazil. The em(4)() driver supports WOL too.
 
Gentlemen,

After a long work, life changed my plans and I don't need the WOL anymore. All what I have now is a partially imported WOL in msk(4) which can be found here as attachment. I think it could be anyway helpful for someone out there to share my experience.

1) The Datasheet Tragedy

It is hard to design anything without a proper solid base of documentation. There was no hope to find the NIC datasheet anywhere online so I decided to contact Marvell directly. Here below the answer I received:

You will need a Marvell Extranet account and permission to access the datasheet for the 88E8059.
Were you able to take a look at the Linux driver?


The latest drivers can be downloaded from *http://www.marvell.com/drivers

Linux Driver Kernel 2.6.x Linux Driver
Under Platform, pick Linux 2.6 - Fedora
Kernel 2.6.x Linux Driver Install Package for Yukon Devices
http://www.marvell.com/support/downloads/driverDownload.do?driverId=153&action=1
Click to expand...

It was somehow expected from my side so no big deal. I decided to move on and dig in the Linux driver (as also suggested in the FreeBSD support documentation). The open question is: why design a product if the world can not freely use it after a legal purchase of it? Probably money and management decisions are behind this.

2) The Linux spaghetti code

Okay it had been ten years I was not dealing with C code, and I also have to admit my brain is an average small one but this code is just confusing. If you compare it to the FreeBSD NIC driver it is like hell and heaven. Basically there is a common part independent from the different OS and the Linux specific part (kernel 2.6). This generates messy structures like double definitions for the same thing and C functions going back and forth between the two worlds making the reading and the understanding hard. Sometime I was wondering and asking myself: “Why so many files and directories in the Linux driver when FreeBSD can do the same thing with one .h and one .c?” I definitely love FreeBSD code, it's more clean and more human(/robot) friendly.

3) What I have (and not) done

Basically I ported almost everything (also ifcap interfaces are supported), only the Linux function SkGmInitMac is not ported yet. This function should initialize the NIC copper interface, reset and set the properly interrupts. At the end of the Linux WOL function I also completely ignore the relationship between the firmware and the OS driver. Since there are no traces of a firmware call in the FreeBSD driver code I don't know what is going on here.

Generally my code reflects 1:1 the Linux driver which takes care not only of the 88E8059 but of all the Marverll Yukon NICs family. I tried to keep all the WOL activities restricted in one WOL function so there are no other WOL external function calls there, and the Linux external calls are nested in one big WOL function.

The only not clean point in the FreeBSD NIC driver is this:

Code: 
DRIVER_MODULE(mskc, pci, mskc_driver, mskc_devclass, 0, 0);
DRIVER_MODULE(msk, mskc, msk_driver, msk_devclass, 0, 0);
DRIVER_MODULE(miibus, msk, miibus_driver, miibus_devclass, 0, 0);

which is basically (in my poor eyes) a driver driving a second driver driving the final one. Now as long as the problem is to port Linux stuff from the first and second driver layer it was relative easy. I experienced big problems when the Linux code was going down in the lower part of the driver, close to the copper interface and far away from the above PCI one. It could be that the solutions are in the module miibus(4), but since I don't need WOL anymore... well good luck.

Moreover I did not test what I coded here at all.

4) What should be added in the WOL FreeBSD support documentation

Saying that implementing the WOL is easy is simply not true nowadays. Chips are more complicated and what was reality in 2007 is different now. Everything depends on the developer's brain efficiency and the quality of the available documentation and open source C code. Moreover a proper implementation should work not only with a single NIC chip variant but with all the NICs supported by the FreeBSD NIC driver. This requires a wide knowledge of the past NICs specifications. It is surely a good exercise for a beginner driver developer.

5) A suggestion for all the FreeBSD NIC driver developers

I imagine those guys with tons of NICs on the table to test, tons of datasheets and a lot of experience in the FreeBSD world. Now in my eyes coding a NIC driver without the WOL support is like to cook a delicious birthday cake without writing with chocolate cream on top “Happy Birthday Mr. Driver”. It is just an incomplete work, and it can be quickly turned into a fully complete one. Unimportant and nice to have code of course but still part of a driver. For you drivers dragons it is really much easier than the others people out there, so if you have one day more to invest just do it and smile at the end.

Here is why you should do it (WOL pros):
  • Energy Saving: One ASUS Crosshair IV with power supply, one old graphic card and 3 SSD (no spinning disks at all!) are draining about 83 W at idle (measured by me) and 110 W on boot. When they are off (with WOL on in the BIOS) we are talking about 15 W.
  • Security: Nobody seems to realize that a powered off system can not be sniffed or accessed by anyone. Period. I have more to say here but this is not the right place.
  • Dust and electronic wear: The less you use a PC the less in theory you are wearing the electronic components. Moreover everybody who has opened the case of a 24/7 (=always on) running system after one-two years of service knows why dust can be a show stopper. Again the less the system works the less dust is accumulating by the cooling fans.
Just to give the full picture, here are the WOL cons:
  • Only people who are able to send the WOL packet to the turned off machine can then use it (maybe a feature?).
  • The system needs to boot up before coming fully online, so you need to wait a little bit before you can access the system.
  • ou can't deal with a WOL machine if you need 24/7 services.
Good luck to all of you who want to continue and surely improve my work. Please remember finally I am just a beginner in the "X"nix system. Excuse me in advance if my post is a stupid one.

Take care,

Z
 

Attachments

@Zucca,

Your post is certainly not a stupid one, but it is slightly out of place on an end-user forum, where almost nobody is involved in writing or inheriting code for drivers ;)

I think the freebsd-drivers mailing list would welcome (and possibly carry on) your contributed code.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top