iwlagn/dhclient fails to get IP address by dhcp

[Rocko]

Intrepid 2.6.27-10-generic and iwlagn on my Dell XPS M1530 with an Intel 4965AGN wireless card has enormous difficultly getting an IP address via DHCP on my work's Belkin wireless network with hidden SSID and WPA-Personal encryption.

Another computer running Intrepid 2.6.27-10-generic and ipw220 connects straight away, and the computer running Intrepid/iwlagn connects straight away if I boot into Hardy 2.6.24-21-generic.

The problem is not in network manager, because it also occurs if I configure the network manually using wpa_supplicant. Nor is it in wpa_supplicant, because the logs show that wpa_supplicant always associates and authenticates successfully with the network. The logs show dhclient sending DHCPDISCOVER requests to the wlan0 interface, so it is working correctly.

So the problem appears to be a regression somewhere between iwlagn and the iwl4965 driver or in the way it communicates with the kernel.

I did manage to connect successfully twice using Intrepid/iwlagn yesterday by setting network-manager to assign a static IP address and then running dhclient manually once the network was authenticated. But this was only twice out of more than 30 attempts. Once connected, the network ran fine without any problems.

I tried a similar configuration on my home network (hidden SSID, WPA) and Intrepid/iwlagn, and didn't have any problems connecting. So this doesn't apply to all networks.

Note that this looks similar to bug #276482, but in my case ipw2200 connects fine to this network.

[Rocko (rockorequin)]

lspci for the wireless card gives:

0b:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
 Subsystem: Intel Corporation Device 1120
 Flags: bus master, fast devsel, latency 0, IRQ 2297
 Memory at f9efe000 (64-bit, non-prefetchable) [size=8K]
 Capabilities: [c8] Power Management version 3
 Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
 Capabilities: [e0] Express Endpoint, MSI 00
 Capabilities: [100] Advanced Error Reporting <?>
 Capabilities: [140] Device Serial Number 29-2f-61-ff-ff-3b-1f-00
 Kernel driver in use: iwlagn
 Kernel modules: iwlagn

[Rocko (rockorequin)]

I tried installing the latest iwlagn module as per http://linuxwireless.org/en/users/Download#DownloadlatestLinuxwirelessdrivers, but this didn't fix the problem.

However, I've found a workaround for the problem by disabling support for 11N networks, ie by:

sudo modprobe -r iwlagn && sudo modprobe iwlagn 11n_disable=1

or by adding 'options iwlagn 11n_disable=1' to /etc/modprobe.d/options to make it permanent.

This works both with the iwlagn module shipped with Intrepid 2.6.27-10-generic and with the latest updated module.

[shr00m (nostrovius)]

I'm having the same exact issue and solved it in the same way by using 11n_disable=1.

Just to add a bit more info, this is not a problem with DHCP.. there is just a large delay between the time the network is connected and before the pc can start receiving packets on that connection. obtaining a DHCP lease fails because it just happens during that initial phase.

Interestingly enough, outgoing packets are received correctly by the remote computer across the wifi link, it's just the incoming replies that do not get through until about a minute or two have passed.

[Vasil Kolev (vasil-ludost)]

I have the same issue (again with the 4965 AGN card) and this happens only on 802.11n (well, draft-n) capable devices. I have one WRT150N at home and see this behavior (which disappears with the 11n_disable=n), and at the office where I use normal WRT54G devices, it doesn't show. Both networks use WPA, but I have seen this with an open network, too.

I have opened a bug on 802.11n support (which seems to be lacking in the kernel), #203506, but nothing really happened there.

[Rocko (rockorequin)]

This bug is still present in Jaunty with kernel 2.6.28-5-generic.

@shr00m - do you know why it takes such a long time before the PC can start receiving packets on the connection? It sounds like this might be a low-level hardware problem instead of a kernel bug, ie we should report this to Intel so they can upgrade their firmware.

[Rocko (rockorequin)]

I still have this problem in the latest Jaunty 2.6.28-6 kernel.

For what it's worth, I believe the wireless AP that I can't get an address from is an 11n AP.

[seagull (john-millington)]

Rocko, this does not happen on same hardware booting into Windows Vista (dual boot set-up). I don't believe it is a firmware problem.

This problem has been reported in multiple instances in launchpad - and the fix described seems to be the only one available at the moment.

[shr00m (nostrovius)]

There are a couple bug reports open with Intel that seem to describe this issue:

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1887
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1871

from the bug reports, the issue affects Fedora and SuSe as well and the intel 5300 card as well not just 4965

[Rocko (rockorequin)]

It's still a problem in 2.6.28-8-generic.

Incidentally, Vista on this laptop can't even see the hidden access point, let alone get a DHCP address, with or without 11n enabled. Computers running WinXP can attach to it but they take up to 60 seconds to get a DHCP address, so it seems that XP might suffer the same bug but is allowing longer before timing out.

[Rocko (rockorequin)]

linux-backports-modules-2.6.28-11-generic version 2.6.28-11.12, which has an updated wireless compatibility stack, seems to have fixed the problem for me - I can now connect to this hidden 11n network and get a dhcp address without the 11n_disable=1 option.

[Rocko (rockorequin)]

Having said that, I get kicked off the network regularly, which wasn't happening before. It then reconnects.

syslog has:

Apr 6 11:31:56 pegasus-jaunty kernel: [ 4026.847284] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:32:09 pegasus-jaunty kernel: [ 4039.718769] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:32:34 pegasus-jaunty kernel: [ 4064.710622] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:32:46 pegasus-jaunty kernel: [ 4077.402472] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:32:59 pegasus-jaunty kernel: [ 4090.102347] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:34:45 pegasus-jaunty kernel: [ 4196.326463] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:34:58 pegasus-jaunty kernel: [ 4209.190470] wlan0: beacon loss from AP ffff88010510cac0 - sending probe request
Apr 6 11:35:00 pegasus-jaunty NetworkManager: <info> (wlan0): supplicant connection state: completed -> disconnected
Apr 6 11:35:00 pegasus-jaunty kernel: [ 4211.188129] wlan0: no probe response from AP ffff88010510cac0 - disassociating
Apr 6 11:35:00 pegasus-jaunty NetworkManager: <info> (wlan0): supplicant connection state: disconnected -> scanning
Apr 6 11:35:08 pegasus-jaunty kernel: [ 4219.138594] wlan0: deauthenticated (Reason: 6)

[Rocko (rockorequin)]

I might have been getting kicked off the network regularly because CRDA was choosing the wrong regulatory domain, ie https://bugs.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.28/+bug/349001.

It was kicking me off the network whether I enabled or disabled 11N, and since I've forced it to the correct domain it has stayed connected.

[rah003 (rah-atlas)]

there seems to be quite similar issue reported for iwl3945 [1] and it's supposed to be fixed in kernel 2.6.30 ... did anybody get a chance to test with 2.6.30-RC4 or later?
[1] http://bugzilla.kernel.org/show_bug.cgi?id=13067

[Rocko (rockorequin)]

I've been using 2.6.30 for some time now, and this bug is fixed (and several other wireless bugs are, too). It's definitely worth upgrading just for the wireless fixes, but there are other important ones too: for instance, the kernel panics you can get using ext4 with 2.6.28 are fixed in 2.6.30.

[seagull (john-millington)]

Rocko, did you download 2.6.30 from kernel.org or is there an ubuntu version somewhere?

[seagull (john-millington)]

Never mind, I found it but nvidia doesn't build.

[Rocko (rockorequin)]

I got the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/, and I downloaded the latest nvidia driver from ftp://download.nvidia.com/XFree86/Linux-x86_64/ (you can get 32-bit ones from that site as well). To install it, you have to change to a console (ctrl-alt-f1), log in, do "sudo killall gdm" to kill the X session, run the installer with "sh <name of file>", and then reboot.

I'm using nvidia 185.18.14, which runs great (it's faster than the 180 series), and I used the attached script which I found somewhere to install it to dkms so it rebuilds automatically when you install new kernels (you have to uninstall the restricted drivers or envy-ng, whichever you used before). You can remove old nvidia modules from dkms with the command "sudo dmks remove -m nvidia -v 185.18.14 --all" (where 185.18.14 is the version; put the appropriate version in instead).

[kernel-janitor (kernel-janitor)]

Hi Rocko,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/karmic .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 305338

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]