This I think is one of those things that will drive any user batty.
I'm trying to install a driver for my Intel internal WLAN, using iwlwifi.
I have upgraded my kernel from 2.6.18 to 2.6.22-3 to get mac80211.
I've tryed several versions (1.0.1 to 1.2.22) of iwlwifi, and they all do the same thing: throw hundreds of errors when I run make to create the iwlwifi.ko module.
I have the source for 2.6.22-3, and the general headers. What I don't have is the 686 specific headers. I've tryed "apt-get install linux-headers-2.6.22-3-686", but this produces the response: linux-headers-2.6.22-3-686 depends on linux-kbuild-2.6.22; however:
Package linux-kbuild-2.6.22 is uninstallable.
I have searched for a manual .DEB file to install kbuild, but they seem to have been removed.


So my question is thus: can I get linux-kbuild-2.6.22 from somewhere else? if not, can I get the 686 headers without kbuild? Do I need to build my own iwlwifi.ko module, can I download one for the 2.6.22-3-686 kernel? Is there a better way to get my WLAN to work?

The driver you need for that card was put into the kernel starting with 2.6.24, so moving at least that far would probably be the easiest solution. If you do need to stick with 2.6.22, I believe you have to patch and recompile the kernel to get the proper mac80211. The patch should be on the Intel site. Also be sure you have the correct firmware installed, although that shouldn't affect the driver compile.

Thanks for that.
I was against upgrading the kernel (but even more so compiling a custom one) so I chose the oldest (and therfore the one that more people had used) that included the mac80211. Since doing it I don't know what I was worryied about, so I'll upgrade the kernel again to 2.6.24 when I boot to linux next (dual boot machine, currently in winXP: the three big things stopping me from going %100 linux are WLAN, UNC paths in wine and active directory).

Does anyone know of any realy show stopping problems with 2.6.24 (this was my original fear with upgrading the kernel in the first pace)? or do you sugest going with a newer/diferent kernel?

I've been using 2.6.24.5 for several months now and not run into any issues. The kernel team has just released 2.6.26, and you might want to check the changelogs to see if there are any changes to the iwl4965 driver that might be worth upgrading. In general, my biggest problem with upgrading the kernel hasn't been hardware, but rather issues with keeping VMware running so if you're not using that (and even then my issue is with one specific aspect of VMware) then I doubt that a newer version of the kernel is going to cause any major issues. However, if you want to remain on the safe side, use the latest 2.6.24.

Thanks for that.
I've just apt-got kernel 2.6.25-5 and all seems good. KWiFiManager now aknowleges the existance of my WLAN, and can pick up the wireless network if it's told what the scsid is but I can't connect to it, the message I'm getting is "out of range" but it hasn't moved (not even an inch) since it was running fine in windows. Soon I'll be decamping to our other office, with a diferent scsid and wep key that I can phisicaly get closer to and I'll see if that makes any diference at all.

In all honesty, the defualt KDE wireless manager seems to leave quite a bit to be desired (and unusable in the command line). Any thoughts on a replacement?

I've been using two GUI wireless managers fairly successfully:

wifi-radar

Wicd

Of the two, I think wicd is probably the more robust solution however it is also a two part solutions. It has a daemon that has to be started independently of the GUI while wifi-radar is just a single program. Both of them are desktop independent and I would bet that they both exist in a Debian repository.

For the command line I just use iwconfig and wpa_supplicant. If you check my help site a long time ago I wrote a perl script that scans for networks and gives you a choice of which to connect to. However it is exceedingly basic and doesn't really handle encrypted networks well. Since wicd and wifi-radar work so well, I've pretty much stopped working on the perl script.

Before I saw your post, I thought prerhaps kwifi needed an upgrade (the version I had was now older than my kernel). I apt-got the new version. That needed a new version of KDE, that needed new core packages, ect, ect. Just doing that took well over two hours, and now konqueror dosen't work (yay). I haven't tryed the new version, but when I do I'll have a look at wifi-radar then wicd afterward.

With the "out of range" thing, does it make any diference do you think, if the access piont is a 'Range Max' that has some sort of signal boosting (and probibly proprietory) system? I'm just wondering if linux dosen't understand it if it's outside the normal range (but inside the rangemax range)

I highly doubt that 'RangeMax' is anything that Linux can't handle. All router signals should fall within 802.11 specifications. Granted, the n stuff is still draft, but a,b and g are quite standard. What router manufacturers seem to be playing around with a lot is the MIMO stuff that uses multiple antennas to grab packets faster and that is completely independent of the OS used on any client machine. The only way that a router manufacturer can truly boost the range of a router is either by messing with antenna design or by boosting the power of the signal. Both of those are covered either by the 802.11 spec and/or FCC regulations (in the US) and won't vary between Windows or Linux clients.

Pretty much that is the long way of saying that I think your connection problem probably has more to do with the way the wireless card is configured than with the actual distance from the router. I suspect the "out of range" message is simply a symptom of some other problem, and in your case Kwifimanager is a very likely culprit. I bet either wicd or wifi-radar will work better.

I couldn't get wicd to work, but whe I ran wifi-radar all I got was:

Over and over again.
What does "Interface dosen't support scanning" mean?

The Wireless Extensions warning is likely a result of your kernel upgrade. You'll need to also upgrade your wireless tools package to the newest version. The homepage is here, but I suspect that your Debian repository has something you can apt-get. Basically that is a warning that the wireless extensions in the kernel are newer than the wireless tools and problems can result.

However, I sometimes see that sort of error ("Interface doesn't support scanning") when I forget to run wifi-radar as root. Since you're messing with the network configuration you need root priviledges. Wicd gets around that by having the daemon run as root and the client can then be run as a normal user. Try upgrading wireless tools first and see if that solves the problem though.

That's a great idear, I hadn't even thought of that.
The good news is I worked out how to connect to the WLAN from the command line: I just use "iwconfig wlan0 ..." then "ifup wlan0". The "Interface dosen't support scanning" thing only happens when the interface is down, if the interface is up, it can scan to it's hearts content. I don't know if that's a problem with the driver or the device itself, but at the moment I don't care.

The funny this is that when I start the machine with no eth0 connection (ie the lan is unpluged on startup) the wlan dosn't work, throwing a error like "can't mount NFS, waiting for eth0" when I use ifup. I only saw this at our other site though. When I get a chance to boot back to linux, I'll do some more rigorous testing.

I think this falls into the category of "its not a bug its a feature". Slackware doesn't behave like this, but a number of other distros do, apparently Debian included.

That sounds more like a configuration issue than anything else. Do you automatically try to mount an NFS drive at boot?

I don't mount a NFS drive, there aren't any on the network. But I don't think that's related to the problem.

I discovered that the wirless actualy dosen't work. All the data I thought was passing through it, isn't. It was going through eth0. The WLAN is connected and even gets an IP number from the DHCP server, which is why I thought it was working but if I unplug eth0 and then try to ping the mail server I get :
PING 10.1.1.1 (10.1.1.1) 56(84) bytes of data.
From 10.1.1.22 icmp_seq=2 Destination Host Unreachable
From 10.1.1.22 icmp_seq=3 Destination Host Unreachable
From 10.1.1.22 icmp_seq=4 Destination Host Unreachable

where 10.1.1.22 is the IP that wlan0 got from the DHCP. Sometimes the IP is 10.1.1.33, which is eth0. The DHCP server confirms that it gave the wireless an IP at the correct time, and the MAC address of the card matches. This tells me it's only talking to itself. The mode type is "Managed" and it is talking to an access piont, but I heard somwhere that some Intel wireless cards have dificulty with ad-hoc networks (although I thought that was to do with the windows driver).

What now?

Just pulling the plug probably doesn't do the trick, you need to take down the interface (ifconfig eth0 down). If you just pull the plug, eth0 is still live.
Sorry, but I think we need to look at some basics here. Please post your ifconfig, iwconfig and route -n outputs after you've configured and brought up just the wireless interface.

Unless you're trying to run and ad-hoc network, this shouldn't come into play. I'm assuming that we're talking about a standard access point/router, not computer to computer connections. Please correct me if I'm wrong.

Sorry to confuse you about the nature of the network, it is indeed several laptops talking to an access point, when I wrote that I was more thinking out loud.

before I saw your post I already thought of taking eth0 down properly using "ifdown eth0" but it doesn't make any deference (except that the error never includes 10.1.1.33 afterwards).

On an unrelated note, I finally got around to trying Ubuntu Hardy Heron live CD last night, and the wireless worked straight away (the first time it ever worked under linux I think); I was surfing the web on it. So that rules out hardware incompatablility or driver (assuming they're the same) issues.

As usual, I'm running WinXP in the morning and I'll switch to linux some time after lunch, so I'll get the output from ifconfig, iwconfig and route -n for you then.