DriverLoader FAQ (Frequently Asked Questions)

The easiest way to verify your driver installation is to connect to the web configuration interface at http://127.0.0.1:18020/ (from the system on which you installed the driver).

If you prefer the command line, you may follow these steps.

First, you should verify if the kernel is able to load the driver module by running "modprobe driverloader" from a root shell and then look for 'driverloader' in the output of "lsmod". The command "dmesg" will usually display a message about the device's detection result.

If the kernel can load the module, then run "dldrconfig --info". This should give you some details on your wireless interface. The license status has to be 'OK'.

In case you don't get any information on your interface, it probably means that there is a problem with your NDIS driver. Make sure that the right driver files are present in '/var/lib/driverloader' or use the web configuration interface to reupload your NDIS driver.

Finally, you can run "ifconfig -a" and "iwconfig" to verify if the network interface is present and accessible by the kernel's wireless extensions.

It is usually best to get the latest version of the Windows XP driver for your device directly from its manufacturer's website.

Alternatively, you can use one which probably came on a CD-ROM with your device.

DriverLoader needs the .INF or .NTF file from the driver as a starting point. Then it will ask you to provide one or more .SYS files and possibly other files as required. All of these files are usually uploaded via the Web Configurator.

If the driver is distributed as a single .ZIP or .EXE file, you should first try to extract its contents with the 'unzip' (or perhaps also 'unrar') utility.

If this doesn't work, you might have to extract or install the driver on a Windows machine first and copy the files from there. Sometimes they end up under C:\Program Files\ManufacturerName\Drivers or similar locations. You might also want to look in C:\WINDOWS\Inf and C:\WINDOWS\System32\Drivers (by displaying the files by date, you should be able to identify the ones recently added for the WLAN adapter).

On the CD-ROM, the .INF, .SYS and possibly other files might be found either in the root folder (but do not choose AUTORUN.INF), or under directories often named "Drivers", "WinXP" or "XP". If no XP version is available, you might be able to use the "Win2K" version.

The absence of the network interface is often a sign that the driver module didn't load or initialize properly.

Try "modprobe driverloader", then check the '/var/log/messages' file or run "dmesg" to see any kernel error messages that could provide a clue as to why loading of the driver failed.

First, make sure you execute the command as root.

If you get the error "No such file or directory" or "Can't locate module driverloader", then you should try to reinstall the module by running the following shell commands as root.

dldrconfig --remove
dldrconfig --auto

Read the output from the second command carefully in case there is a problem while installing the module.

Once the 'driverloader' module is working properly, you should configure the new interface with your Linux distribution's usual network configuration tools.

If these tools require that the interface name to be something different than "ethN", (e.g. wlanN), you can change it with "dldrconfig --netdevname".

It is preferable to use your Linux distribution's network configuration mechanism (which in turns probably calls 'iwconfig' to set WLAN parameters when bringing up the interface).

You can run "man iwconfig" to get a description of the parameters.

Please refer to your distribution's documentation for more details on the network interfaces configuration.

These errors are due to the network script trying to set parameters that are not supported by your device or NDIS driver.

They are usually harmless, but sometimes indicate that one of settings you wanted is unavailable.

The wireless parameters and statistics are device dependent. Please run "man iwconfig" in a shell for more details.

First, make sure that your AP is detected by running the command "iwlist scan".

If you can't see your AP, verify your driver and license status with the command "dldrconfig --info". Also make sure that it's not due to a bad RF signal (AP too far, loose antenna, etc.).

Otherwise, if your AP shows up but you cannot connect to it, then make sure that your WEP settings are correctly configured and that your wi-fi adapter's MAC address is allowed to attach to your AP. If possible, you should reset your AP's configuration to its default.

It is a good idea to test with WEP disabled on both the AP and your computer. Then when things work, incrementally enable additional options.

In some cases, transmission problems can occur if you are using the wrong NDIS driver making it impossible to associate with the AP. Make Make sure that you uploaded the Windows XP binary file(s) through the web interface and not the Win9x one(s). You can also test with a different driver version if available.

Verify on which channel your access point is configured. Due to country regulations, some cards cannot receive channels 12-14. If your access point's current channel is set in that range, try changing it to between 1 and 11.

You have to make sure that you are using the same WEP settings on your access point and on your client side.

Some versions of the wireless-tools have been compiled with a different interface than the kernel. Use "iwconfig --version" to verify that they match. If not, your wireless-tools package might need to be updated.

There are sometimes compatibility problems when the Access Point key mode is set to "automatic" so you can try to choose "open system" or "shared key" instead.

Add the keyword "open" after your 64 or 128 bit WEP key when using the command "iwconfig" to configure your client in "open system" mode.

Add the keyword "restricted" after your 64 or 128 bit WEP key when using the command "iwconfig" to configure your client in "shared key" mode.

e.g.: iwconfig key $key restricted
(replace $key with your real encryption key)

Presently, DriverLoader supports PCI, CardBus, and USB devices.

32-bit CardBus adapters, unlike legacy 16-bit PCMCIA cards, have a gold strip on their connector.

Linuxant is always working to extend the compatibility of DriverLoader and legacy PCMCIA devices might be supported eventually.

Yes, and it can be safely ignored.

This problem might be ACPI-related or caused by an IRQ issue related to the APIC. You can verify if your kernel is using APIC by looking for the line "ENABLING IO-APIC IRQs" when you run the shell command "dmesg".

If you experience this problem, try disabling ACPI and/or the APIC by booting your kernel with the option "acpi=off" and/or the option "noapic".

The 'wireless-tools' package is required by DriverLoader.

'wireless-tools' should be installed from your Linux distribution CD. If your distribution supports RPM, then the install command should be similar to this: rpm -i /path/to/rpms/wireless-tools-....rpm

It is very important that the driver module be compiled with the same compiler version that was used to build your kernel.

If the wrong version is used (i.e. gcc2 instead of gcc3 or vice-versa) the system may crash or refuse to load the module.

You can use the commands "cat /proc/version" and "gcc -v" to check the version strings.

By default, 'dldrconfig' looks for the symbolic link '/lib/modules/(kernelversion)/build'
If this link exists and points to a valid directory, then 'dldrconfig' will use this directory as the kernel sources' location.

If the link does not exist, 'dldrconfig' will try to use '/usr/src/linux' or '/usr/local/src/linux'.

Note that if your kernel sources are in '/usr/local/src/linux', but you also have a '/usr/src/linux' link pointing to an invalid or empty directory, then 'dldrconfig' will try to use '/usr/src/linux' and it will fail.

The kernel source tree must be exactly the same that was used to build the kernel that you are running. Otherwise, 'dldrconfig' might refuse to build the module or the driver will not work properly.

Try the following command:

rpm -e --noscripts --allmatches driverloader

If the driver prevents your system from starting normally, you could try booting in 'single user' or 'failsafe' mode first.

You can verify if the 'webconfd' process is running with the shell command "ps -C webconfd".

If 'webconfd' is not active, you can execute "modprobe driverloader" in a root shell to start it. However, if the module is not loadable (not properly compiled, missing, etc.), then you will need to fix this problem before trying to configure the driver. Refer to the corresponding FAQ question.

If the web configuration is still unaccessible even with 'webconfd' running, then you might be missing some Perl modules. This can be verified with the following shell commands:

cd /usr/lib/driverloader
for i in webconfd webconfdocs/cgi-bin/*.cgi; do perl -c $i; done

Make sure that you enter "root" in the 'User Name' field and root's password in the 'Password' field.

DriverLoader is an NDIS (Network Driver Interface Specification) wrapper. If your device uses NDIS, then we might be able to support it in a future version of DriverLoader.

We are planning to make DriverLoader as generic and device-independent as possible.

The driver module is separate from your kernel, but it must have been compiled using the same sources. This means that whenever you upgrade your kernel, you have two possibilities:

1) Download the driver package from Linuxant's web site that corresponds to your new kernel version - if it's a very recent kernel, we might not have released a package for it yet.

2) Use the generic drivers (downloadable from Linuxant's web site) instead of using drivers specific to a single Linux distribution and kernel. To use the generic drivers, the kernel source tree used to build the kernel that you are running has to be installed. When using the kernel supplied by your Linux distribution, you can simply install the "kernel-source" package.

With the generic drivers, you can easily recompile the module after upgrading your kernel by running the following command:

dldrconfig --kernel

Generally not yet, but programs like tcpdump in promiscuous mode should work if the Windows NDIS driver does offer that functionality.

Monitoring/spy modes are usually not officially supported by NDIS, only promiscuous mode. Programs like Netstumbler often use proprietary (driver-specific) NDIS extensions which we do not support yet.

As for the "wireless signal" softwares, DriverLoader provides the RSSI (receive signal strength indicator) as signal level, but the signal quality and noise values are not supported due to NDIS limitations. Quality is always 1/1 and noise -200 dBm - they are just "placeholder" values.

Make sure that your kernel is compiled with the support for 'wireless extensions'. You must enable 'Wireless LAN' under 'Network device support'. The options in the configuration file are 'CONFIG_NET_RADIO=y' and 'CONFIG_NET_WIRELESS=y'.

Before installing a package, 'rpm' tries to verify its integrity. This usually does not prevent you from installing the package.

The packages distributed by Linuxant are cryptographically signed with our public PGP key, which is not known to 'rpm' by default. However, it can be found on many keyservers or downloaded from the following address:

At this time, we only distribute Linux drivers and there are currently no plans to support other operating systems.

However, people interested in porting the drivers to other operating systems should contact us.