Background:- I've written here before about ndiswrapper, which I've deployed successfully to support several different wireless cards under SL3. Primarily, in our group I've deployed an inexpensive card based on the rt2500 chipset, which works well on Windows, as well as in SL3 under ndiswrapper. However, under SL4 there is a standoff situation: the available kernels are built with the 4KSTACKS option, but, as warned in the ndiswrapper notes, quite a few of the Win32 drivers will crash under these conditions; ndiswrapper recommends rebuilding the kernel without the 4KSTACKS option, but this seems like overkill just to get a wireless card to work, and would turn into a maintenance nightmare for the users. Consequently I've also been keeping an eye on native linux drivers for the rt2500 chipset. This note records some initial success. Native rt2500 drivers:- The chipset vendor offers source code from their support page at http://www.ralinktech.com/supp-1.htm - unfortunately I've not been successful in building any of those under SL. The rt2x00 (originally "rt2400") sourceforge project offers several source code packages developed from ralinktech released source. See: http://rt2x00.serialmonkey.com/wiki/index.php/Downloads Looking at rt2x00-v2.0.0-b3, it said it was for kernel versions of at least 2.6.13: attempting to build it for SL4 was not successful. Looking at rt2500-v1.1.0-b3 on the other hand, I *have* been successful in building this, both for SL3.0.3 and for SL4 (4.2 to be exact). Both of the systems on which it had been tried had previously been set up to use ndiswrapper, but I commented that out in modules.conf (resp. modprobe.conf). In SL4, it appeared to me to be necessary to run "depmod" manually, after installing the kernel module. One thing I haven't yet understood is that the kernel module, although claiming to support a device name of wlan0 when built for Fedora Core, or ra0 for everything else, in fact seems to come up "all by itself" as eth1 when I try it on SL ("eth0" being the wire Ethernet). I haven't yet understood how/why it does this without having to be given an explict "options" setting. Building the GUI "utility" RaConfig2500 (in the quaintly-named "Utilitys/" subdirectory) requires "qt" and "qt-devel" to be installed. In my case, I had to do "yum install qt-devel", and afterwards open a fresh shell window, before following the recipe for building the GUI utility. When executed without modification, the utility consistently alerts that the device driver could not be found, and then exits. I modified the source code for raconfig.cpp to change the hard-coded reference to "ra%d" to be "eth%d", and rebuilt it. It then works, provided that the rt2500 kernel module has been previously loaded. It looks very similar to the configuration utility provided by Ralinktech in their Windows package. I'm successfully using it with WPA-PSK security, at least from "root". Note that, unlike ndiswrapper, this does not require the wpa_supplicant package - the WPA-PSK support is somehow built-in. The RaConfig2500 GUI utility is not the only way to configure the setup. For example, it says it honours a configuration file, or can be configured via iwconfig/iwpriv low-level commands. In fact, the GUI utility contains a hard-coded test for uid zero, so the utility can only be successfully executed by "root". We would want to be able to run the wireless card from an unprivileged user account, so I'd be looking at one of the other configuration methods (that's on my TODO list). There seems to be a bit of incompatibility between the available network configuration features in the standard SL setup (gnome network control panel, hot-plugging support etc.), and the features which come with this source-code package. I haven't entirely got these under control yet. Hope that's useful to somebody. If anyone can fill in some of the open questions above, please go ahead. We nevertheless have a few users whose laptops have built-in wireless facilities for which we haven't found a native driver compatible with SL. So there is still a "market" for ndiswrapper, if it ever can be got working safely in SL4. But I don't think I can do anything about that personally - I'm doing no more than keeping a watching brief on developments, in the hope that something emerges.