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.
|
