Wireless networking, however, is a bit of a throwback to the old days. Half the hardware doesn’t have Linux drivers, and half of the devices that do require you to hunt for the driver — based on the chipset, of course, not on the name or model number on the box — and compile it yourself. (At least these days, you can sometimes run a tool to adapt the Windows drivers if there’s no native Linux option.)

The steps I actually needed to take to set up wifi on my Fedora 13 desktop probably only amounted to about 10 minutes. Unfortunately it took a lot of false starts to get there. I had installed a Zonet ZEW1642 PCI card, which my initial research suggested would be supported by the built-in rt2860 drivers. As it turned out, it wasn’t that simple.

First, what didn’t work:

• Built-in drivers.
• The rt2860 drivers (or any others) from RPMFusion.
• Manually configuring the card with system-config-network (even after I got the right driver installed).

What did work:

• Download the driver and firmware from Ralink’s Linux website.
• Build and install the driver.
• Start using NetworkManager.

Key Info

1. lspci reports the card as:Network controller: RaLink Device 3062
2. It doesn’t use the rt2860 driver.
3. When the driver works, the card will show up as ra0 when you run ifconfig or iwconfig. If you run either of those and don’t see ra0, or if you try to configure ra0 and get a message like “unknown device,” you don’t have the right driver loaded.
4. When the driver works, NetworkManager will automatically recognize it. You don’t need to configure the interface first. (This tripped me up several times.)
5. The NetworkManager and network services conflict with each other. You have to pick one and disable the other.

Most of the information I found on this card…wasn’t actually about this card, but about related ones. What little I did find implied that it uses the same driver as the rt2860. It doesn’t. Well, not exactly. They use the same firmware, and the config file for the rt3062 is called RT2860STA.dat, which confuses the issue.

Howto

1. Go to Ralink’s Linux page and download the appropriate driver and firmware based on the model number.
2. Unzip the firmware
3. As root, copy rt280.bin to /lib/firmware/rt2860.bin
4. Unzip the driver source file (ex: tar xvf /download/linux/drivers/2010_07_16_RT3062_Linux_STA_v2.4.0.0.tar)
5. Step into the folder and read the instructions in README_STA
   1. You probably won’t need to change the Makefile or set compiler flags, but you will need to set it to work with either NetworkManager or wpa_supplicant. So edit os/linux/config.mk and set HAS_WPA_SUPPLICANT=y and HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y (for NetworkManager). If you don’t change this, it will not work. (Don’t worry about the next coulple of lines about wpa_supplicant. They don’t seem to be necessary from what I can tell.)
   2. Build it by typing make in the main folder of the source archive.
   3. As root, copy RT2860STA.dat to /etc/Wireless/RT2860STA/RT2860STA.dat
6. At this point, you can diverge from the directions a bit.
7. To install, switch to root and run make install in the main folder of the archive. This should copy rt3562sta.o to the appropriate location for your system.
8. If you haven’t been using NetworkManager, again as root, run service network stop to disable the standard network service (since it conflicts with NetworkManager).
9. Enable the driver: again as root, run modprobe rt3562sta
10. If you have NetworkManager running, it should immediately recognize the card and detect nearby networks.
11. Once you’ve got everything working, as root, run chkconfig --del network to permanently disable the other daemon. (But make a note of this in case you ever switch back.)

One more thing: keep this folder around! Because of the way Linux drivers work, you’ll need to re-install the drivers the next time your system updates to a new kernel. This is a pain, and is the reason I was hoping the built-in drivers or RPMFusion packages would work. More on that in the next section.

Follow-Through

Rebooting: Because I had previously removed NetworkManager from my system, I had to make sure the Gnome desktop would load the NM applet. That was fixed by going to System→Preferences→Startup Applications and enabling Network Manager.

Kernel Updates: I haven’t had to do this yet, but based on experience with other Red Hat-based systems where I’ve had to use third-party drivers, here’s how to reinstall the driver the next time Fedora sends you a kernel update.

After the new kernel is installed, but before you reboot, go back to the driver folder and run the following:

1. make clean
2. make
3. sudo make install (or just switch to root and run make install)
4. sudo modprobe rt3562sta (or stay as root and just run modprobe)

That should take care of it. If you forgot to do this first (and are reading this article on another computer), just run modprobe rt3562sta (as root) after you’re done.

Update: I originally suggested rebuilding the module before rebooting, but the Makefile automatically detects the running kernel. You can manually force it to use the source from the newer kernel, but for the sake of these directions, this way is simpler.

This 18-page thread at Fedora Forum was very informative, though it did point me in a few wrong directions.

The error message it kept popping up was:

The operation can’t be completed because you don’t have permission to access some of the items.

So it didn’t have permission to access or save the items, but it had permission to delete them? Clearly the error message wasn’t telling the whole story!

Even stranger: if I opened a file with an application like TextWrangler or NeoOffice, they had no problem saving it! It was only Finder that had the problem!

Now, I’ve successfully transferred files back and forth between these computers many times before, but I had changed two things recently:

• Upgraded the Linux box to Fedora 13.
• Installed the Mac OS X 10.6.4 update to Snow Leopard.

I didn’t have much luck searching online, maybe because I was looking for the wrong terms. The closest I came up with were discussions like this one, but they all involved a server using netatalk or other AFP file sharing implementations. I’ve been using samba (Windows-Style SMB shares) on the Linux box ever since I had some problems with Netatalk and decided that since the Mac would connect via Samba, I wouldn’t worry about it.

I idly posted the problem on Twitter. My brother replied that he’d run into the same problem (on Ubuntu, IIRC), and suggested turning off Unix extensions in Samba. That meant opening up /etc/samba/smb.conf on the Linux box and adding the following line to the “Filesystem Options” section:

unix extensions = no

I restarted Samba on the Linux box, and that was it. The Mac was able to copy files over without any errors!

I hope this post helps someone else solve the same problem.

This stupid “OMG Nepomuk is not running!” error has been dogging me every time I launch KMail, ever since Fedora upgraded KDE. I followed all the directions on fixing Akonadi, and nothing worked. Finally, it turned out that there was a config file telling it to load the old-style “redland” database — which doesn’t exist in current versions of Nepomuk — instead of the new “virtuoso” database.

The file was in ~.kde/share/config/nepomukserverrc and the item in question is “Used Soprano Backend.” I changed it from “redland” to “virtuosobackend” as described here and now it actually starts Nepomuk, and KMail doesn’t complain when I start it!

Someone at KDE decided to massively overcomplicate things!

*grumble*

I thought a major point of PulseAudio was to let applications share the sound card cleanly. *grumble* Sound worked fine before Fedora switched. I can’t even blame it on a bleeding-edge distribution, since from what I hear, Ubuntu has similar problems.

At least now I know (sort of) why it stopped again after applying the Complete guide to fix PulseAudio and video/audio VLC Media Player issues.

So I put it off for a few days.

Today I decided to try it.

The automatic upgrade program is called preupgrade, presumably because it downloads everything you need in order to prepare for the upgrade. It downloads everything while your system is up and running, then sets it up so that when you reboot, it will launch the installer. It installs everything, makes the changes, then reboots into the newly upgraded system.

And then it’s done.

It’s network aware, and works through yum, so it will actually take into account both third-party repositories and anything that’s been updated since the new release. It actually went out to livna.org RPM Fusion and picked up the appropriate NVIDIA display drivers.

Download while you work. Reboot. Wait. Done.

The only snafu I ran into was that it removed my copy of the Flash plugin, but I think I was using the experimental 64-bit one anyway, so it’s not terribly surprising.

I get the impression that Ubuntu has had a similarly smooth upgrade process for a while. And after my experiences moving from Fedora 9 to Fedora 10, I was seriously considering jumping ship. (Hazards of living on the bleeding edge.) But it looks like I won’t have to.

Now I just have to find time to play around and see what’s new!