Bug 239959 - starting xend makes wake on lan not work
Summary: starting xend makes wake on lan not work
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xen
Version: 6
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Xen Maintainance List
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-13 12:34 UTC by Jeff Layton
Modified: 2014-06-18 07:36 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-27 00:11:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jeff Layton 2007-05-13 12:34:27 UTC
I was attempting to get my home workstation set up to wake on lan and was having
trouble. After some experimentation, I've determined that after shutting down, I
can wake the machine only if xend wasn't started. Some info about my setup:

Ethernet Interface:
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

Packages:
kernel-xen-2.6.19-1.2911.6.5.fc6
xen-3.0.3-8.fc6

...I've configured WOL by setting this in ifcfg-eth0:

ETHTOOL_OPTS='wol g'

...if I start xend and run "ethtool peth0", I see:

        Wake-on: g

...but after shutdown ether-wake from another host will not wake the machine. If
I chkconfig xend off, then it works without issue.

I know kernel is older, but 2.6.20-based xen kernels are unstable on my machine.
I did test kernel-xen-2.6.20-1.2948.fc6, and it showed the same issue, so I
think this is likely a userspace problem. Let me know if there's any other info
that would be helpful or if you need me to test anything.

Comment 1 Andy Gospodarek 2007-05-22 18:21:57 UTC
I haven't specifically reproduced this yet, but since Xen does some funny stuff
with the MAC address that most-likely interferes with WoL on nvidia hardware.

I'd be curious to see how well it worked with some of the other WoL methods:

       wol p|u|m|b|a|g|s|d...
              Set Wake-on-LAN options.  Not all devices support this.  The
argument to this option is a string of characters specifying which options to
enable.
              p  Wake on phy activity
              u  Wake on unicast messages
              m  Wake on multicast messages
              b  Wake on broadcast messages
              a  Wake on ARP
              g  Wake on MagicPacket(tm)
              s  Enable SecureOn(tm) password for MagicPacket(tm)
              d  Disable (wake on nothing).  This option clears all previous
options.

like specifically ARP or broadcast.





Comment 2 Jeff Layton 2007-05-22 19:07:05 UTC
Unfortunately:

# ethtool peth0 | grep Wake-on
        Supports Wake-on: g
        Wake-on: g

...I *did*, however, verify that switching the networking to network/vif-nat
works around the issue. So the changing MAC addrs does seem likely to be the
problem. When xend starts, it changes the name of the physical interface to
"peth0" and changes its MAC address to "FE:FF:FF:FF:FF:FF". Going to see if I
can wake it up using that addr...


Comment 3 Jeff Layton 2007-05-22 19:14:52 UTC
That didn't work either -- but then again, I'm not terribly suprised :-)



Comment 4 Jeff Layton 2007-05-24 14:16:37 UTC
Another data point...

If I shut down xend and then run:

/etc/xen/scripts/network-bridge stop

and then shut down the machine, I can wake the machine up as well.
network-bridge stop seems change the MAC address back on the physical interface.
It looks like xend does not run this when it shuts down. I'm not sure if this is
by design or not...



Comment 5 Jeff Layton 2007-05-24 14:45:28 UTC
I guess you can shutdown (or restart) xend with domains still running, so I'm
not sure if we want to tear down the networking stuff when it shuts down. Maybe
the best solution is to just add a new shutdown script that tears down the
networking just before the "real" networking is torn down.

I'll hack something together as an example, but we may want to write a python
prog that just calls Vifctl.network("stop") when run.


Comment 6 Chris Lalancette 2008-02-27 00:11:42 UTC
This report targets FC6, which is now end-of-life.

Please re-test against Fedora 7 or later, and if the issue persists, open a new bug.

Thanks



Note You need to log in before you can comment on or make changes to this bug.