Going Back To VMware For Now
Posted by Stuart Herbert @ 8:55 AM, Mon 10 Jul 06
Filed under: Gentoo
9 Comments
For the last week or so, I’ve tried running Linux natively on my laptop. VMware’s a great piece of software, but the overhead of running Gentoo as a guest O/S gets to be a problem at times. Performance for CPU-intensive tasks (like compiling) is good, but anything that’s disk I/O intensive (like booting, or cvs up) takes a lot longer. Memory usage is also an issue, because some of the RAM has to be left for Windows XP. (Well, a bit more than “some”, alas).
The reason I have a laptop is that I’m never sat at a desk at home. I probably spend more time online from wireless hotspots than I do via wireless @ home. For me, wireless has to work, otherwise I can’t get things done.
And, although it’s definitely getting there, one week with wireless on Linux has convinced me to switch back to VMware for now.
Forgetting driver issues (everyone knows about those, and why card manufacturers are reluctant to release open-source drivers), there are three issues that have convinced me to switch back:
- Unreliable connection
- Trouble with hotspots
- Gentoo baselayout and daemon support
Unreliable Connection
I’ve repeatedly had problems with connecting to access points in the first place. wpa_supplicant often needs several tries before it can authenticate (whenever this happens, it does this thing where it tries authenticating against a bssid of 00:00:00:00:00:00). For open & WEP-protected networks, switching to wireless-tools avoids this problem. I don’t have a problem w/ having to use the wireless-tools (instead of wpa_supplicant) for open & WEP-protected networks, but unfortunately I’ve had the wireless driver crash a couple of times when using them, forcing a reboot to fix things.
It’s not just me; I watched on Saturday as Tim was also having problems connecting to a wireless network.
The situation in Windows actually isn’t much better in general. At work, we’ve had lots of trouble trying to get all the laptops working with the same encryption scheme at the same time. (Our experience is that Sony laptops are extremely temperamental on this. YMMV). But I’m lucky (I guess) because wireless under Windows works great with my Dell Inspiron.
Trouble With Hotspots
Unreliable I can live with (hey, I put up with evo for a year <grin>), but not being able to get onto the Internet via wi-fi hotspots is something that I can’t live with.
I have a BT Openzone account. Thanks to the Wireless Broadband Alliance, it works on plenty of other networks too - including the T-Mobile hotspots that you can find in pretty much any Starbucks. If you’ve never used a hotspot, they do this thing where, once you have an IP address, when you open up your browser you’re redirected to their login page. Only after you’ve logged in can you then access the wider Internet.
And, unfortunately, I haven’t once managed to get connected to a T-Mobile hotspot using Linux natively. The wireless interface reports that it is associated with the hotspot, but the DHCP client can’t get an IP address.
When I have some free time, I need to use Ethereal on Windows to see how Windows connects to the hotspot, and then compare that with the process under Linux. That should show me what I’m not doing right, with a bit of luck.
But me and free time are creatures that have fleeting meetings at best 
Gentoo Baselayout and Daemon Support
If you’re a roaming user, the idea of starting up a wireless connection when you boot the box has limited appeal. The process Windows uses makes a lot of sense:
- Start up the wireless interface
- Connect to any “preferred” wireless network, if one is available
- Assign an unroutable IP address if no “preferred” wireless network is available
As best as I can tell, our current stable baselayout is missing step 3. If wlan0 is not associated with an access point, it has no IP address. Which leads on to the problem with daemons …
The problem with our daemons is that many of them require networking to be started (’use net’ in their init script’s depend() function) otherwise they won’t start. Stable baselayout doesn’t seem to consider starting lo as satisfying the ‘net’ dependency, so stuff doesn’t start.
Having the wireless always considered to be started (even if it’s using the fallback, unroutable IP address) would solve this problem nicely.
Update: see the comments for how to configure baselayout to treat ‘lo’ as satisfying the ‘net’ dependency, and how to fallback to a static IP address if wireless cannot connect. I’ll give these a try the next time I boot natively.
The Advantage Of Using VMware On Laptops
The nice thing about running Windows XP as the host o/s on a laptop is that all of these problems simply go away. It handles all the wireless for you; your Linux guest o/s simply sees what it thinks is a wired network connector. No more problems with wireless drivers under Linux either (which probably goes a long way to the stability).
And you get added benefits like suspend to disk 
Some high-profile kernel folks seem believe in a world where suspend to disk isn’t a feature that Linux needs. Personally, it’s an important feature for me. I don’t use suspend to RAM, and it’s not a feature that I personally find remotely useful.
I’ll give Linux wireless another go at some point in the future, but, tbh, once I get my Merom-based laptop, I’m expecting VMware’s performance to be good enough that I probably won’t need to think about native booting anyway. (It’s more likely to be running under Parallels than VMware, fingers crossed).
9 Comments
July 10th, 2006 at 9:21 am
Stuart,
There’s a switch to make baselayout think that lo is enough of an adaptor to have up and running. You can find it in /etc/conf.d/rc:
# RC_NET_STRICT_CHECKING allows some flexibility with the ‘net’ service.
# The following values are allowed:
# none - The ‘net’ service is always considered up.
# no - This basically means that at least one net.* service besides net.lo
# must be up. This can be used by notebook users that have a wifi and
# a static nic, and only wants one up at any given time to have the
# ‘net’ service seen as up.
# lo - This is the same as the ‘no’ option, but net.lo is also counted.
# This should be useful to people that do not care about any specific
# interface being up at boot.
# yes - For this ALL network interfaces MUST be up for the ‘net’ service to
# be considered up.
RC_NET_STRICT_CHECKING=”lo”
Hope that helps…
Mike 5:)
July 10th, 2006 at 9:26 am
Well, both points you mentioned against linux/gentoo are just untrue.
1) wpa_supplicant can connect to WPA/WEP/unencrypted networks, no need for any other software. Together with kwlan oder wpa_gui it can behave just like windows.
2) Getting a static IP in case dhcp fails is no problem at all, just use apipa as fallback. e.g. in /etc/conf.d/net:
config_wlan=(”dhcp”)
dhcpcd_wlan=”-t 5″
fallback_wlan=(”apipa”)
July 10th, 2006 at 9:29 am
Have you already tried NetworkManager, which is available in the gentopia overlay?
I have it up an running for a while and had few problems connecting to wireless networks (I never tried to connect to T-Mobile hotspots).
If you haven’t tried it yet you should because it’s simple and just works.
Regards,
–Joris
July 10th, 2006 at 1:06 pm
This seems like an obvious suggestion but have you tried suspend2-sources? They work great on my Vaio. I used to have some issues with wireless and 3D acceleration breaking after resume but that’s all fine now.
As for wireless, I use wpa_supplicant. I hate digging around in /etc/conf.d/wireless just to join a new network. wpa_supplicant has a nice little GUI tool for switching networks and managing encryption keys.
Sorry I couldn’t make it to Gentoo UK this year!
July 10th, 2006 at 1:18 pm
Ikelos: thank you for that. I’ll definitely try that setting!
Christian: I’m sorry, but I don’t see how you can say that my experience is ‘untrue’. I agree that wpa_supplicant is documented as being able to work with open & WEP-based networks, but when I’ve tried it, I get the problems I’ve mentioned above. Thanks for the tip about the fallback_wlan setting. That’ll prove very useful indeed.
Joris: I haven’t tried NetworkManager. I’ve heard a lot about it, but I’ll wait until it’s merged into the Portage tree before trying it. I have a working desktop at the moment, and am reluctant to risk trying Gentopia in case everything breaks. Maybe I’ll clone the virtual machine, and try Gentopia on that instead
July 10th, 2006 at 3:40 pm
James: There’s always next year
I’ve used wpa_gui, but it’s only as reliable as the underlying wpa_supplicant … which in turn is only as reliable as the underlying wireless driver.
The other issue I noticed with wpa_supplicant is that it is always seeking for a network. I get better battery life out of Linux than I do from Windows + VMware, but I could get even more battery life if wpa_supplicant didn’t try to reconnect all the time.
July 10th, 2006 at 6:17 pm
Stuart: wpa_supplicant versions older than 0.5.4 mostly fail with WEP or open networks, 0.5.4 and newer has worked 100% for me.
Another key component is to use baselayout-1.12.1 as it allows for network re-entrancy and init script sheduling which basically means the startup sequence won’t pause when it searchs for networks.
net.wlan starts
net.wlan uses netplugd so goes “inactive”
net.wlan starts
net.wlan uses wpa_supplicant so goes “inactive”
openvpn is scheduled to start when net.lan or net.wlan does
nfsmount is scheduled to start when openvpn does
As you can see that’s quite powerful as openvpn-2.1_beta supports baselayout-1.12 re-entrancy and can go inactive itself.
July 11th, 2006 at 8:31 pm
i wrote an initscript for my wlan:
#####################
#!/sbin/runscript
depend()
{
need modules
}
wlan_check()
known”
not known”
{
ebegin ” checking for wlans”
tmp=/tmp/wlan_check$$
for i in `iwlist s 2>/dev/null | grep ESSID: | cut -d : -f 2`; do
echo $i;
done > $tmp
for i in `cat $tmp`; do
known=1
for x in `awk ‘{ print $1 }’ /etc/conf.d/wlans`; do
if [ $i == $x ]; then
known=0
fi
done
if [ $known == 0 ]; then
einfo ” $i t
echo “$i” > /tmp/wlan_to_connect
else
einfo ” $i t
fi
done
rm $tmp
if [ -e /tmp/wlan_to_connect ]; then
eend 0
return 0
else
eend 1
return 1
fi
}
wlan_connect()
{
if [ -e /tmp/wlan_to_connect ]; then
ebegin ” connecting to wlan”
essid=`cat /tmp/wlan_to_connect | cut -d ‘”‘ -f 2`
key=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 4`
iwconfig eth1 essid $essid key $key
ok=$?
eend $ok
fi
return $ok
}
network_start()
{
ebegin ” starting network”
if [ -e /tmp/wlan_to_connect ]; then
essid=`cat /tmp/wlan_to_connect | cut -d ‘”‘ -f 2`
ip=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 6`
mask=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 8`
broadcast=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 10`
route=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 12`
ifconfig eth1 $ip netmask $mask broadcast $broadcast && route add default gw $route
fi
ok=$?
eend $ok
return $ok
}
network_end()
{
ebegin ” ending network”
ifconfig eth1 down
ok=$?
eend $ok
return $ok
}
localoption()
{
if [ -e /tmp/wlan_to_connect ]; then
essid=`cat /tmp/wlan_to_connect | cut -d ‘”‘ -f 2`
rm /tmp/wlan_to_connect
option=`grep $essid /etc/conf.d/wlans | cut -d ‘”‘ -f 14`
$option
fi
}
start()
{
wlan_check
wlan_connect
netzwerk_start
localoption
}
end()
{
network_end
}
################
the format for /etc/conf.d/wlans is
“essid” “key” “my ip address” “subnetmask” “broadcast” “gateway” “optional command”
July 12th, 2006 at 2:44 pm
I use networkmanager too and its much better than hacking around scripts.
i just select the network and let gnome handle teh stuff. since i do that it works like a charm (well it did before), but, its also very simple and straight (well, it didn’t before ;p)
honestly, network manager IS the holy graal for me.
now if only software suspend would be FASTER (as fast as windows xp)
Add Your Comments To This Article Using The Form Below
Your comments may not appear until they have been approved by a moderator.