Hello,
I'm still configuring my wireless interface manually using iwconfig, and
do not run any management daemons like wpasupplicant etc. This provides
the basic functionality I'm interested in.
But from time to time, I get the message
"No ProbeResp from current AP <ap address> - assume out of range"
and then my connection is dead. I've found no other way out of this
(using only iwconfig/ifconfig) than trigger a reassociation by
temporariliy configuring different (non-existing) essid.
The wireless network consists of a large number of APs, and there are
always more than one accessible AP when this error occurs. I suppose
the reason for the probe failure may be a temporary AP failure
(crash/whatever). However, as you can see from the log below, the error
condition is permanent after such a timeout - even if the associated AP
become available again. It does associate with the same AP after
manually triggering reassociation.
I'm currently using the iwlagn driver as you can see, but I've
previously had the same (or similar?) issues with both the ath5k and the
b43 driver.
-> iwconfig wlan0 essid "bar"; ifup wlan0
Apr 28 08:13:10 nemi kernel: [272487.353682] iwlagn 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
Apr 28 08:13:10 nemi kernel: [272487.353857] iwlagn 0000:03:00.0: irq 26 for MSI/MSI-X
Apr 28 08:13:10 nemi kernel: [272487.379825] Registered led device: iwl-phy1:radio
Apr 28 08:13:10 nemi kernel: [272487.379853] Registered led device: iwl-phy1:assoc
Apr 28 08:13:10 nemi kernel: [272487.379877] Registered led device: iwl-phy1:RX
Apr 28 08:13:10 nemi kernel: [272487.379906] Registered led device: iwl-phy1:TX
Apr 28 08:13:11 nemi kernel: [272487.395683] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Apr 28 08:13:11 nemi kernel: [272487.404641] wlan0: direct probe to AP 00:22:90:f9:63:b2 try 1
Apr 28 08:13:11 nemi kernel: [272487.407965] wlan0 direct probe responded
Apr 28 08:13:11 nemi kernel: [272487.407970] wlan0: authenticate with AP 00:22:90:f9:63:b2
Apr 28 08:13:11 nemi kernel: [272487.410950] wlan0: authenticated
Apr 28 08:13:11 nemi kernel: [272487.410954] wlan0: associate with AP 00:22:90:f9:63:b2
Apr 28 08:13:11 nemi kernel: [272487.414565] wlan0: RX AssocResp from 00:22:90:f9:63:b2 (capab=0x421 status=0 aid=1)
Apr 28 08:13:11 nemi kernel: [272487.414569] wlan0: associated
Apr 28 08:13:11 nemi kernel: [272487.419542] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Apr 28 08:13:21 nemi kernel: [272497.760019] wlan0: no IPv6 routers present
-> then it works until:
Apr 28 09:51:31 nemi kernel: [278388.088590] wlan0: No ProbeResp from current AP 00:22:90:f9:63:b2 - assume out of range
-> which leaves the interface in a non-functional state until I do:
-> iwconfig wlan0 essid "foo"; iwconfig wlan0 essid "bar"
Apr 28 10:13:05 nemi kernel: [279681.489584] wlan0: direct probe to AP 00:22:90:f9:63:b2 try 1
Apr 28 10:13:05 nemi kernel: [279681.492237] wlan0 direct probe responded
Apr 28 10:13:05 nemi kernel: [279681.492242] wlan0: authenticate with AP 00:22:90:f9:63:b2
Apr 28 10:13:05 nemi kernel: [279681.494645] wlan0: authenticated
Apr 28 10:13:05 nemi kernel: [279681.494651] wlan0: associate with AP 00:22:90:f9:63:b2
Apr 28 10:13:05 nemi kernel: [279681.497428] wlan0: RX AssocResp from 00:22:90:f9:63:b2 (capab=0x421 status=0 aid=3)
Apr 28 10:13:05 nemi kernel: [279681.497434] wlan0: associated
I've been trying to get a grasp of what happens here, and am wondering
whether it would make sense to force a scan after a direct probe
timeout? Could this be done with something like:
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 132938b..a12c408 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -679,6 +679,7 @@ static void ieee80211_direct_probe(struct ieee80211_sub_if_data *sdata)
* due to state == IEEE80211_STA_MLME_DIRECT_PROBE.
* Hence, queue the STAs work again
*/
+ set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
queue_work(local->hw.workqueue, &ifmgd->work);
return;
}
I'm of course going to test this, but it would help alot if someone
knowing the code could say "that's ridiculous" or "please test". The
error condition is quite rare, and I guess I'll have to test for weeks
to be somewhat certain whether a workaround really helps or not.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
