Bug 16619 - iwlagn on Centrino Ultimate-N 6300: wlan0: direct probe to [ap mac] timed out
Summary: iwlagn on Centrino Ultimate-N 6300: wlan0: direct probe to [ap mac] timed out
Status: CLOSED DUPLICATE of bug 16462
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 high
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks: 16055
  Show dependency tree
 
Reported: 2010-08-18 15:20 UTC by andreas.neiser
Modified: 2010-08-18 23:03 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.35.2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg output with accidentally working wireless (51.04 KB, application/octet-stream)
2010-08-18 15:36 UTC, andreas.neiser
Details
lspci -vvv of the wireless card (2.13 KB, application/octet-stream)
2010-08-18 15:37 UTC, andreas.neiser
Details
kernel config 2.6.35 (110.20 KB, application/octet-stream)
2010-08-18 15:37 UTC, andreas.neiser
Details
dmesg with IWL_DEBUG=y and NOT WORKING wireless (probe time out) (493.87 KB, application/octet-stream)
2010-08-18 20:12 UTC, andreas.neiser
Details

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 ***

Note You need to log in before you can comment on or make changes to this bug.