Variable Winds – Building Wifi Drivers the hard way.

I initially got Wifi set up using a .deb file but in my messing around I broke it. I set it up on the earlier kernel the hard way by making a driver as per the Wind User Wiki but nothing I could do made it start automatically on the latest kernel and a dmesg showed dozens of errors. So back to building drivers the hard way again.

The reason we have to build the drivers is that they need information on the exact version of linux you are running and they need to be rebuilt for every version so when you get a new version in your updates which is significant enough to have a new Grub loader entry you will need to rebuild the drivers which is a pain – that is why most of the common drivers are already included in the kernel update. The drivers are written either by the device manufacturer or by enthusiasts if no linux version is available and are in a uniform format to make use easy. In some cases they may need so fine tuning for a particular machine and they are then refereed to as a fork as the basic updates are lost until a new ‘fork’ is created. That is the case for the Wind Wifi driver which needed a couple of minor changes to compile and run on the Wind hardware, for example, machines differ in how the Wifi is turned on and off (Fn Key versus switch etc) . The fork has been created in the last few weeks by Coffelius and is also the basis of the .deb file I first used initially.

The following is what I did on the older kernel version 2.6.24.19 where there was no .deb available – it worked perfectly and started every time the machine booted up. It assumes the driver download is called rtl8187se_coffee, this case it was a fork from the standard rtl8187 driver (‘fork’ version 4) by coffelius downloadable from http://code.google.com/p/msi-wind-linux/ – there is a lot of extra information on that page and has the links to debian installer and install scripts which are further discussed in the Wind Forums .

sudo apt-get install build-essential
sudo apt-get linux-headers-`uname -r`
tar zxf rtl8187se_coffee.tar.gz
cd rtl8187se_coffee
./makedrv
sudo cp -r ieee80211/*.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/
sudo cp rtl8185/r8180.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless/

sudo rm -rv /lib/modules/`uname -r`/kernel/drivers/net/wireless/rtl8187.ko
sudo rm -rv /lib/modules/`uname -r`/kernel/net/ieee80211
sudo rm -rv /lib/modules/`uname -r`/ubuntu/wireless/rtl8187-usb

sudo modprobe -r r8180
sudo depmod -a
sudo modprobe r8180

Now a brief explanation of what is being done.

The first line install two utilities into your system which are used in the building of the utilities. This is a once off activity but it will tell you if they already exist.

The second line fetches the information about your kernel so exactly matching drivers can be built. This is needed for each new kernel version but again it will not cause problems if you do it an extra time.

The driver comes as a compressed archive which is in a standard format and when extracted creates a subdirectory of where it is run with the same name which contains all the files needed to create the drivers and some scripts to help create and ‘install’ the drivers which assume they are run from within the same folder. That is why we needed to get the latest ‘headers which contain the information needed to build a driver specific to your version.

We now change to the directory containing the extracted files so we can run the script.

The script makedrv now compiles the actual drivers we need based on its own data and that in the linux kernel header file. What we end up with are local copies.

The next two lines copy them to the standard places on the machine. The `uname -r` is replaced by the current header when the line is used in a terminal. Note they are back quotes which are at the top left of the keyboard. You can find out the header by typing just uname -r in a terminal. [There is also a script which could be called by ./install with many drivers to do this but it assumes standard places and the original forum postings did not use it, perhaps because the positions are non standard. ]

The next block of lines of three lines should be used with caution – they remove all the other versions of similar drivers on the machine – see the footnote as to why this is required. I have included them in case I ever turn this into a script. An alternative way is to rename all the files ending in .ko in the folders above to .kop so that they can not be found by depmod -a when it is called below. You can use gksudo nautilus to run a GUI filehandler as root to make the destruction easy.

The next line makes sure that any existing versions are removed which prevent the new driver being installed.

The next line sets up the dependences for the automatic install every time the machine starts.

And the final line both loads the drive and makes the driver available for when the machine starts up.

As stated before this procedure should be adequate for a one off install on a fresh kernel version and worked perfectly on kernel version 2.6.24-21-generic for me without the file deletions. The equivalent via a .deb worked until I messed something up trying to sort out other drivers for the Webcam which must have changed the order that depmod picked up the files. I spent a long time experimenting and investigating and now know a lot more about the relevant terminal commands modprobe, lsmod, dmesg, modprobe -l and finally the one that gave the game away modinfo. Many produce a lot of output and piping to grep to filter it is useful to try dmesg | grep 81 which will find all lines in the main log with an 81 in them.

Whilst trying to sort out the problem which has been reported by many people I discovered that the folder with the drivers contains two scripts to start and stop Wifi from the terminal and I found I could start Wifi on the latest kernel by using the script wlan0up and stop it with wlan0down. Note they have to be run from within the same directory.

I initially did a quick and dirty fix to avoid having to run a terminal command as root every time by setting up a script to implement the above scripts and run it every time at startup. The system runs many system scripts at startup and on Ubuntu they are run by symbolic links in the /etc/rc2.d folder (for normal startup at run level 2) to scripts generally kept in the /etc/init.d folder. I did not put the script in the usual place nor arrange it to have standard startup and power down interfaces.

I adding an extra symbolic link to my own script WifiStart by opening a terminal window and typing

sudo ln -s /home/pcurtis/bin/StartWifi /etc/rc2.d/S99wifi

The script file StartWifi, needs to be owned by root and with permissions set up for everyone, I found the easiest way to create this was to use the file browser nautilus but opened as root by typing

sudo nautilus

in a terminal window. I then right clicked in the home directory and created the folder bin, opened the folder and then created the file StartWifi and immediately right clicked to properties and the permissions tab where I set read write and execute for everyone. I then double clicked to open it and selected edit to add the contents and then saved it.

#!/bin/bash # Check that we are running under the correct kernel kernel=`uname -r`
driverkernel="2.6.24-21-generic"
if [ $kernel = $driverkernel ]
then
# change to directory where the driver was initially made
cd /home/pcurtis/rtl8187se_coffee
# Run script to stop wifi and unload drivers from the kernel in case they are still present
/home/pcurtis/rtl8187se_coffee/wlan0down
# Now install the drivers into the kernel and start the Wifi running
/home/pcurtis/rtl8187se_coffee/wlan0up
fi

Note that I have a check to make sure it is only run on the problematic kernel – it would insert the wrong drivers on other versions.

Note that this is going to be run by root at startup so the sudo is not needed. I chose ~/bin as the home as this was a quick fix and ~/bin is the normal home for user scripts. If you do it properly and use /etc/init.d as the directory the script ought to implement start, stop and resume parameters which is extra work. One last thing to remember is that the file must be given permissions for execution by everyone including root by

chmod x ~/bin/StartWifi

I hope all this will not be needed by anybody but it may give hints as to how to get round problems as well as an insight into the need and implementation of building drivers. You can see basically the same initial job was needed in my posting on Webcam drivers.

Then I found the solution which has been fed back into the above but the following cautionary note gives an understanding of such problems may be useful to others

A cautionary footnote on Wifi and other drivers.

I am begriming to understand how the driver installation has been going pear shaped. First one needs to know that all the modules which are available are .ko files and depmod -a is run every time the machine boots up. This recreates the dependency tree and satisfies it by searching all the standard areas for .ko files. So we have great scope for problems if the system has a driver in place as well as the driver we are loading and they use the same file names because they come from the same original source – this means that we can have our new driver having its dependencies satisfied by an old file if depmod finds it first. I have been trying out modinfo which I had read about and found that at least on of the new drivers dependencies is being satisfied by a similar file in an ubuntu folder – this crossing of files must have been leading to all the error messages and I can now see why some of the scripts I have seen delete other folders, I had renamed some as a precaution but that did not stop the automated search. You will see the problem if you do a Find Files using the panel tool for ieee80211*.ko and you will find that versions exist in several places, there should be versions in each kernel but not two in any kernel.

I have not yet backed up and/or renamed all these files yet but it is nice to have found a likely source of the problem. The current solution works by forcing a new set of drivers every time by unloading the old ones from the kernel and reinstalling my new ones. If it aint broke don’t fix it! especially when we need the machine shortly.

In the longer term I wonder if one should install into the standard ubuntu locations. Either way I wonder what other devices depend on these files, I use a USB Wifi dongle at times which is more sensitive than the little built in ones and I do not want that to lose its drivers.

Footnote 2

I finally renamed all the duplicates in the ubuntu directories to .kop and everything seems to now be working as one would expect. I have fed the changes which are required back into the procedure. I have also verified that it has not stopped my USB dongle being detected and I can turn off the onboard wireless and plug in the dongle at which point the network manager gives me two Wifi interfaces to choose from which is perfect.

I have a further concern and that is that a kernel update or patch of a very minor type which would not require an update of the drivers ie 2.6.24-21.43 to 2.6.24-21.47 may mean that all the old driver files return to haunt us, I wonder if that is what initially killed my system? I will keep my startup script in place but doing nothing just in case, or perhaps do an automatic deletion of all the files at every re-boot – it would be quicker than unloading and loading all the wifi kernel modules!

Leave a Comment

Your email address will not be published. Required fields are marked *