Bug 16619

Summary:	iwlagn on Centrino Ultimate-N 6300: wlan0: direct probe to [ap mac] timed out
Product:	Drivers	Reporter:	andreas.neiser
Component:	network-wireless	Assignee:	drivers_network-wireless (drivers_network-wireless)
Status:	CLOSED DUPLICATE
Severity:	high	CC:	linville, rjw, wey-yi.w.guy
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.35.2	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	16055
Attachments:	dmesg output with accidentally working wireless lspci -vvv of the wireless card kernel config 2.6.35 dmesg with IWL_DEBUG=y and NOT WORKING wireless (probe time out)

Description andreas.neiser 2010-08-18 15:20:18 UTC

When using 2.6.35.2 my wireless does not connect to the AP (using Archlinux and Networkmanager), no data seems to be transferred. dmesg output is:

iwlagn 0000:03:00.0: PCI INT A disabled
iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux, in-tree:
iwlagn: Copyright(c) 2003-2010 Intel Corporation
iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
iwlagn 0000:03:00.0: setting latency timer to 64
iwlagn 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
iwlagn 0000:03:00.0: Tunable channels: 13 802.11bg, 24 802.11a channels
iwlagn 0000:03:00.0: irq 48 for MSI/MSI-X
iwlagn 0000:03:00.0: loaded firmware version 9.193.4.1 build 19710
phy1: Selected rate control algorithm 'iwl-agn-rs'
ADDRCONF(NETDEV_UP): wlan0: link is not ready
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 1)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 2)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 3)
wlan0: direct probe to 00:04:0e:6b:80:e6 timed out
...last lines repeat...

It works flawlessly with 2.6.34.3, this seems to be a regression. For some distro specific details have a look at the bug report here:
http://bugs.archlinux.org/task/20492
Please let me know if you need any further information, don't know how to debug this efficiently...

Comment 1 andreas.neiser 2010-08-18 15:35:07 UTC

While preparing some additional files, the connection now works accidentally, but time-outs still appear:

EXT4-fs (sda3): re-mounted. Opts: discard,commit=0
EXT4-fs (sdb1): re-mounted. Opts: commit=0
fuse init (API version 7.14)
3:2:2: endpoint lacks sample rate attribute bit, cannot set.
3:2:2: endpoint lacks sample rate attribute bit, cannot set.
3:2:2: endpoint lacks sample rate attribute bit, cannot set.
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 1)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 2)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 3)
wlan0: direct probe to 00:04:0e:6b:80:e6 timed out
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 1)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 2)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 3)
wlan0: direct probe to 00:04:0e:6b:80:e6 timed out
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 1)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 2)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 3)
wlan0: direct probe to 00:04:0e:6b:80:e6 timed out
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 1)
wlan0: direct probe to 00:04:0e:6b:80:e6 (try 2)
wlan0: direct probe responded
wlan0: authenticate with 00:04:0e:6b:80:e6 (try 1)
wlan0: authenticated
wlan0: associate with 00:04:0e:6b:80:e6 (try 1)
wlan0: associate with 00:04:0e:6b:80:e6 (try 2)
wlan0: RX AssocResp from 00:04:0e:6b:80:e6 (capab=0x451 status=0 aid=1)
wlan0: associated

I'm going to attach a full dmesg, config and lspci output.

Comment 2 andreas.neiser 2010-08-18 15:36:41 UTC

Created attachment 27495 [details]
dmesg output with accidentally working wireless

Comment 3 andreas.neiser 2010-08-18 15:37:16 UTC

Created attachment 27496 [details]
lspci -vvv of the wireless card

Comment 4 andreas.neiser 2010-08-18 15:37:52 UTC

Created attachment 27497 [details]
kernel config 2.6.35

Comment 5 andreas.neiser 2010-08-18 15:40:38 UTC

Well, now after rmmod iwlagn && modprobe iwlagn the wireless still works!

Comment 6 wey-yi.w.guy 2010-08-18 19:34:19 UTC

sorry, I am confuse, do we have a problem or not?

Thanks
Wey

Comment 7 andreas.neiser 2010-08-18 20:10:49 UTC

Hi Wey,
I think yes. The previous comment seems to be a lucky coincidence (don't know what I changed, and as you can see the time-outs were still there but then suddenly the probe was successful). Now I can't connect, I attached dmesg with IWL_DEBUG=y to the bug report.

Comment 8 andreas.neiser 2010-08-18 20:12:13 UTC

Created attachment 27498 [details]
dmesg with IWL_DEBUG=y and NOT WORKING wireless (probe time out)

Comment 9 andreas.neiser 2010-08-18 20:22:38 UTC

Ah, I found something: 

My Wireless is on channel 12, and I found in the dmesg:

ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=1 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=2 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=3 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=4 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=5 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=6 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=7 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=8 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=9 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=10 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=11 prob=0x3 [ACTIVE 36]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=12 prob=0x2 [PASSIVE 120]
ieee80211 phy1: U iwl_get_channels_for_scan Scanning ch=13 prob=0x2 [PASSIVE 120]

Why are ch12/13 passive? Although `iwlist f` says that it's available:

...
          Channel 12 : 2.467 GHz
          Channel 13 : 2.472 GHz
...

Changing my AP to channel 11 seems to resolve the problem!

Comment 10 wey-yi.w.guy 2010-08-18 20:43:32 UTC

looks like duplicate of
https://bugzilla.kernel.org/show_bug.cgi?id=16462

Comment 11 John W. Linville 2010-08-18 20:45:44 UTC


*** This bug has been marked as a duplicate of bug 16462 ***