No ProbeResp - assume out of range

No ProbeResp - assume out of range

[Luis R. Rodriguez]

I'm curious if others are getting this frequently as I am:

No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range

I get this with ath5k and ath9k, can be triggered easily in ath5k by
doing a lot of consecutive:

iwlist wlan0 scan

I have to check if I can trigger this with ath9k by scanning too. We
were seeing this with ath9k but were thinking it was ath9k related as
it can be triggered on it after doing a large TX. Wondering if this is
more of a generic and mac80211 issue.

  Luis

Re: No ProbeResp - assume out of range

[Michael Buesch]

On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
> I'm curious if others are getting this frequently as I am:
> 
> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
> 
> I get this with ath5k and ath9k, can be triggered easily in ath5k by
> doing a lot of consecutive:
> 
> iwlist wlan0 scan
> 
> I have to check if I can trigger this with ath9k by scanning too. We
> were seeing this with ath9k but were thinking it was ath9k related as
> it can be triggered on it after doing a large TX. Wondering if this is
> more of a generic and mac80211 issue.

IMO this is a mac80211 issue.
mac80211 immediately assumes the connection is broken, if one probe-resp
to a keekalife-proberequest is lost.
So if you scan just after the request got sent, you'll never receive the response
and mac80211 will terminate the connection.
It should try a few times, instead, before blowing up things.

-- 
Greetings Michael.

Re: No ProbeResp - assume out of range

[Luis R. Rodriguez]

On Sun, Nov 2, 2008 at 2:03 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
>> I'm curious if others are getting this frequently as I am:
>>
>> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
>>
>> I get this with ath5k and ath9k, can be triggered easily in ath5k by
>> doing a lot of consecutive:
>>
>> iwlist wlan0 scan
>>
>> I have to check if I can trigger this with ath9k by scanning too. We
>> were seeing this with ath9k but were thinking it was ath9k related as
>> it can be triggered on it after doing a large TX. Wondering if this is
>> more of a generic and mac80211 issue.
>
> IMO this is a mac80211 issue.
> mac80211 immediately assumes the connection is broken, if one probe-resp
> to a keekalife-proberequest is lost.
> So if you scan just after the request got sent, you'll never receive the response
> and mac80211 will terminate the connection.
> It should try a few times, instead, before blowing up things.

Agreed, and I can trigger this without scanning BTW, do we simply bail
out immediately if *one* probe response was not received?

  Luis

Re: No ProbeResp - assume out of range

[Davide Pesavento]

2008/11/2 Luis R. Rodriguez <mcgrof@gmail.com>:
> I'm curious if others are getting this frequently as I am:
>
> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
>
> I get this with ath5k and ath9k, can be triggered easily in ath5k by
> doing a lot of consecutive:
>
> iwlist wlan0 scan
>
> I have to check if I can trigger this with ath9k by scanning too. We
> were seeing this with ath9k but were thinking it was ath9k related as
> it can be triggered on it after doing a large TX. Wondering if this is
> more of a generic and mac80211 issue.
>

I was hitting this quite often with ath9k when using the laptop from
my room, which is a couple of rooms away from the AP. Note however
that under MacOS X the connection is fine and stable, so it shouldn't
be a signal strength problem.

Regards,
Davide

Re: No ProbeResp - assume out of range

[Tomas Winkler]

On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
>> I'm curious if others are getting this frequently as I am:
>>
>> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
>>
>> I get this with ath5k and ath9k, can be triggered easily in ath5k by
>> doing a lot of consecutive:
>>
>> iwlist wlan0 scan
>>
>> I have to check if I can trigger this with ath9k by scanning too. We
>> were seeing this with ath9k but were thinking it was ath9k related as
>> it can be triggered on it after doing a large TX. Wondering if this is
>> more of a generic and mac80211 issue.
>
> IMO this is a mac80211 issue.
> mac80211 immediately assumes the connection is broken, if one probe-resp
> to a keekalife-proberequest is lost.
> So if you scan just after the request got sent, you'll never receive the response
> and mac80211 will terminate the connection.
> It should try a few times, instead, before blowing up things.

I've seen this happening  in high traffic with some APs but it can be
also NIC issue. It needs to really investigate the sniffer capture I
wouldn't assume its only mac80211 issue.  Probe is issued only when RX
is not received for some time so there is some problem, nevertheless
monitoring beacons is a better approach from my experience.

Tomas

Re: No ProbeResp - assume out of range

[Michael Buesch]

On Sunday 02 November 2008 23:29:35 Luis R. Rodriguez wrote:
> On Sun, Nov 2, 2008 at 2:03 PM, Michael Buesch <mb@bu3sch.de> wrote:
> > On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
> >> I'm curious if others are getting this frequently as I am:
> >>
> >> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
> >>
> >> I get this with ath5k and ath9k, can be triggered easily in ath5k by
> >> doing a lot of consecutive:
> >>
> >> iwlist wlan0 scan
> >>
> >> I have to check if I can trigger this with ath9k by scanning too. We
> >> were seeing this with ath9k but were thinking it was ath9k related as
> >> it can be triggered on it after doing a large TX. Wondering if this is
> >> more of a generic and mac80211 issue.
> >
> > IMO this is a mac80211 issue.
> > mac80211 immediately assumes the connection is broken, if one probe-resp
> > to a keekalife-proberequest is lost.
> > So if you scan just after the request got sent, you'll never receive the response
> > and mac80211 will terminate the connection.
> > It should try a few times, instead, before blowing up things.
> 
> Agreed, and I can trigger this without scanning BTW,

Yeah, me too. This can happen on normal life packet loss. It just
has to lose the right packet. :)

> do we simply bail 
> out immediately if *one* probe response was not received?

Last time I looked, the code was pretty much that way.
It's a bit complicated, as it uses some statemachine, but I think
it bailed out after one failure. Dunno how the code looks today,
but I bet it's pretty much the same.

-- 
Greetings Michael.

Re: No ProbeResp - assume out of range

[Luis R. Rodriguez]

On Sun, Nov 2, 2008 at 2:42 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <mb@bu3sch.de> wrote:
>> On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
>>> I'm curious if others are getting this frequently as I am:
>>>
>>> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
>>>
>>> I get this with ath5k and ath9k, can be triggered easily in ath5k by
>>> doing a lot of consecutive:
>>>
>>> iwlist wlan0 scan
>>>
>>> I have to check if I can trigger this with ath9k by scanning too. We
>>> were seeing this with ath9k but were thinking it was ath9k related as
>>> it can be triggered on it after doing a large TX. Wondering if this is
>>> more of a generic and mac80211 issue.
>>
>> IMO this is a mac80211 issue.
>> mac80211 immediately assumes the connection is broken, if one probe-resp
>> to a keekalife-proberequest is lost.
>> So if you scan just after the request got sent, you'll never receive the response
>> and mac80211 will terminate the connection.
>> It should try a few times, instead, before blowing up things.
>
> I've seen this happening  in high traffic with some APs but it can be
> also NIC issue. It needs to really investigate the sniffer capture I
> wouldn't assume its only mac80211 issue.  Probe is issued only when RX
> is not received for some time so there is some problem, nevertheless
> monitoring beacons is a better approach from my experience.

Agreed if it can be NIC issue, but it seems to be a common issue now
across a few drivers, not just ath5k/ath9k.

Hm, ieee80211_rx_mgmt_beacon() is not being hit with ath5k, something is fishy.

  Luis

Re: No ProbeResp - assume out of range

[Luis R. Rodriguez]

On Sun, Nov 02, 2008 at 02:58:49PM -0800, Luis R. Rodriguez wrote:
> On Sun, Nov 2, 2008 at 2:42 PM, Tomas Winkler <tomasw@gmail.com> wrote:
> > On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <mb@bu3sch.de> wrote:
> >> On Sunday 02 November 2008 22:05:56 Luis R. Rodriguez wrote:
> >>> I'm curious if others are getting this frequently as I am:
> >>>
> >>> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
> >>>
> >>> I get this with ath5k and ath9k, can be triggered easily in ath5k by
> >>> doing a lot of consecutive:
> >>>
> >>> iwlist wlan0 scan
> >>>
> >>> I have to check if I can trigger this with ath9k by scanning too. We
> >>> were seeing this with ath9k but were thinking it was ath9k related as
> >>> it can be triggered on it after doing a large TX. Wondering if this is
> >>> more of a generic and mac80211 issue.
> >>
> >> IMO this is a mac80211 issue.
> >> mac80211 immediately assumes the connection is broken, if one probe-resp
> >> to a keekalife-proberequest is lost.
> >> So if you scan just after the request got sent, you'll never receive the response
> >> and mac80211 will terminate the connection.
> >> It should try a few times, instead, before blowing up things.
> >
> > I've seen this happening  in high traffic with some APs but it can be
> > also NIC issue. It needs to really investigate the sniffer capture I
> > wouldn't assume its only mac80211 issue.  Probe is issued only when RX
> > is not received for some time so there is some problem, nevertheless
> > monitoring beacons is a better approach from my experience.
> 
> Agreed if it can be NIC issue, but it seems to be a common issue now
> across a few drivers, not just ath5k/ath9k.
> 
> Hm, ieee80211_rx_mgmt_beacon() is not being hit with ath5k, something is fishy.

OK I found the issue with ath5k, no beacons were being passed at all, I'll post
a patch.

  Luis

Re: No ProbeResp - assume out of range

[Kalle Valo]

Tomas Winkler <tomasw@gmail.com> writes:

>> mac80211 immediately assumes the connection is broken, if one probe-resp
>> to a keekalife-proberequest is lost.
>> So if you scan just after the request got sent, you'll never receive the response
>> and mac80211 will terminate the connection.
>> It should try a few times, instead, before blowing up things.
>
> I've seen this happening  in high traffic with some APs but it can be
> also NIC issue. It needs to really investigate the sniffer capture I
> wouldn't assume its only mac80211 issue.  Probe is issued only when RX
> is not received for some time so there is some problem, nevertheless
> monitoring beacons is a better approach from my experience.

I agree, monitoring received beacons and the number of failed
transmissions would be better. But on the other hand some broken APs
might work better if we periodically send frames to them.

-- 
Kalle Valo

Re: No ProbeResp - assume out of range

[Felix Fietkau]

Luis R. Rodriguez wrote:
> OK I found the issue with ath5k, no beacons were being passed at all, I'll post
> a patch.
Why not configure the beacon miss interrupt instead of passing beacons to
mac80211 in STA mode? That should save some battery on Laptops because it 
won't cause 10 extra wakeups every second.

- Felix

Re: No ProbeResp - assume out of range

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

On Mon, 2008-11-03 at 17:48 +0100, Felix Fietkau wrote:
> Luis R. Rodriguez wrote:
> > OK I found the issue with ath5k, no beacons were being passed at all, I'll post
> > a patch.
> Why not configure the beacon miss interrupt instead of passing beacons to
> mac80211 in STA mode? That should save some battery on Laptops because it 
> won't cause 10 extra wakeups every second.

We have no way to indicate to mac80211 that the hw is watching beacons,
so that'd be equivalent to just dropping them. We've discussed such API,
and I hope somebody will implement it :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: No ProbeResp - assume out of range

[Bharat Bhushan]

On Mon, Nov 3, 2008 at 11:20 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2008-11-03 at 17:48 +0100, Felix Fietkau wrote:
>> Luis R. Rodriguez wrote:
>> > OK I found the issue with ath5k, no beacons were being passed at all, I'll post
>> > a patch.
>> Why not configure the beacon miss interrupt instead of passing beacons to
>> mac80211 in STA mode? That should save some battery on Laptops because it
>> won't cause 10 extra wakeups every second.
>
> We have no way to indicate to mac80211 that the hw is watching beacons,
> so that'd be equivalent to just dropping them. We've discussed such API,
> and I hope somebody will implement it :)
>
> johannes
>

if we start dealing with beacons in NIC, i think this will impact
roaming scenarios, beacouse in most of  roaming algorithms signal
strength of beacon received played a pivot rolef and  ignoring this at
NIC  this will not allow client to take judicious decisions.

bharat

Re: No ProbeResp - assume out of range

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Mon, 2008-11-03 at 17:48 +0100, Felix Fietkau wrote:
>> Luis R. Rodriguez wrote:
>> > OK I found the issue with ath5k, no beacons were being passed at all, I'll post
>> > a patch.
>> Why not configure the beacon miss interrupt instead of passing beacons to
>> mac80211 in STA mode? That should save some battery on Laptops because it 
>> won't cause 10 extra wakeups every second.
>
> We have no way to indicate to mac80211 that the hw is watching beacons,
> so that'd be equivalent to just dropping them. We've discussed such API,
> and I hope somebody will implement it :)

I need it for power saving so I definitely have to implement it,
unless someone else is faster :) I have few other things on my backlog
(eg. roaming and PSM timeout), but after I have finished those I'll
start working on beacon filtering.

-- 
Kalle Valo

Re: No ProbeResp - assume out of range

[Kalle Valo]

"Bharat Bhushan" <bharat.b.bhushan@gmail.com> writes:

>>> Why not configure the beacon miss interrupt instead of passing beacons to
>>> mac80211 in STA mode? That should save some battery on Laptops because it
>>> won't cause 10 extra wakeups every second.
>>
>> We have no way to indicate to mac80211 that the hw is watching beacons,
>> so that'd be equivalent to just dropping them. We've discussed such API,
>> and I hope somebody will implement it :)
>
> if we start dealing with beacons in NIC, i think this will impact
> roaming scenarios, beacouse in most of  roaming algorithms signal
> strength of beacon received played a pivot rolef and  ignoring this at
> NIC  this will not allow client to take judicious decisions.

The NIC should send an event to the driverinforming about the low
signal strength situation and driver will forward this information to
mac80211. The firmware has knowledge of the beacon rssi so this should
be trivial to implement in firmware. But if the firmware really
doesn't support this, the driver can always disable beacon filtering
feature in mac80211.

-- 
Kalle Valo

Re: No ProbeResp - assume out of range

[Michael Buesch]

Well, so it seems this is caused by the driver honoring the filter flag for
beacons. b43 and b43legacy do this, too. So they most likely have the same
misbehaviour.
In the end, I'd still call this a mac80211 bug. Why does mac80211 suppress
beacons (by clearing the flag), if it needs them?

-- 
Greetings Michael.

Re: No ProbeResp - assume out of range

[Bob Copeland]

On Tue, Nov 4, 2008 at 6:17 AM, Michael Buesch <mb@bu3sch.de> wrote:
> Well, so it seems this is caused by the driver honoring the filter flag for
> beacons. b43 and b43legacy do this, too. So they most likely have the same
> misbehaviour.
> In the end, I'd still call this a mac80211 bug. Why does mac80211 suppress
> beacons (by clearing the flag), if it needs them?

The patch in question disables all beacons, not just ones coming from
other bssid.

-- 
Bob Copeland %% www.bobcopeland.com

Re: No ProbeResp - assume out of range

[Christoph Hellwig]

On Sun, Nov 02, 2008 at 01:05:56PM -0800, Luis R. Rodriguez wrote:
> I'm curious if others are getting this frequently as I am:
> 
> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
> 
> I get this with ath5k and ath9k, can be triggered easily in ath5k by
> doing a lot of consecutive:
> 
> iwlist wlan0 scan
> 
> I have to check if I can trigger this with ath9k by scanning too. We
> were seeing this with ath9k but were thinking it was ath9k related as
> it can be triggered on it after doing a large TX. Wondering if this is
> more of a generic and mac80211 issue.

I'm seeing this all the time with ath9k.  For now I'm running with the
following local hack:

Index: linux-2.6/net/mac80211/mlme.c
===================================================================
--- linux-2.6.orig/net/mac80211/mlme.c	2008-11-04 18:10:41.000000000 +0100
+++ linux-2.6/net/mac80211/mlme.c	2008-11-04 18:10:56.000000000 +0100
@@ -972,7 +972,7 @@ static void ieee80211_associated(struct 
 				       "current AP %s - assume out of "
 				       "range\n",
 				       sdata->dev->name, print_mac(mac, ifsta->bssid));
-				disassoc = 1;
+//				disassoc = 1;
 			} else
 				ieee80211_send_probe_req(sdata, ifsta->bssid,
 							 ifsta->ssid,

which makes the problem of an actual disassociation after this message
go away which made wireless completely unuseable with -rc3 for.  Given
that the message never appears a second time just increasing the time
it appears that just increasing IEEE80211_MONITORING_INTERVAL should
fix the problem, too.

Re: No ProbeResp - assume out of range

[Luis R. Rodriguez]

On Tue, Nov 4, 2008 at 10:19 AM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Nov 02, 2008 at 01:05:56PM -0800, Luis R. Rodriguez wrote:
>> I'm curious if others are getting this frequently as I am:
>>
>> No ProbeResp from current AP 00:DE:AD:BE:EE:FF - assume out of range
>>
>> I get this with ath5k and ath9k, can be triggered easily in ath5k by
>> doing a lot of consecutive:
>>
>> iwlist wlan0 scan
>>
>> I have to check if I can trigger this with ath9k by scanning too. We
>> were seeing this with ath9k but were thinking it was ath9k related as
>> it can be triggered on it after doing a large TX. Wondering if this is
>> more of a generic and mac80211 issue.
>
> I'm seeing this all the time with ath9k.  For now I'm running with the
> following local hack:
>
> Index: linux-2.6/net/mac80211/mlme.c
> ===================================================================
> --- linux-2.6.orig/net/mac80211/mlme.c  2008-11-04 18:10:41.000000000 +0100
> +++ linux-2.6/net/mac80211/mlme.c       2008-11-04 18:10:56.000000000 +0100
> @@ -972,7 +972,7 @@ static void ieee80211_associated(struct
>                                       "current AP %s - assume out of "
>                                       "range\n",
>                                       sdata->dev->name, print_mac(mac, ifsta->bssid));
> -                               disassoc = 1;
> +//                             disassoc = 1;
>                        } else
>                                ieee80211_send_probe_req(sdata, ifsta->bssid,
>                                                         ifsta->ssid,
>
> which makes the problem of an actual disassociation after this message
> go away which made wireless completely unuseable with -rc3 for.  Given
> that the message never appears a second time just increasing the time
> it appears that just increasing IEEE80211_MONITORING_INTERVAL should
> fix the problem, too.

I posted a patch which enables beacons to be received by the STA --
this however, as was pointed out by the patch that disabled the beacon
filter on ath5k (note not ath9k, but ath9k also had it disabled),
increases the number of interrupts on the device, as it seems it
enables beacons not only for the BSSID you are on but for all BSSIDs.
Not sure what other devices support and how their beacon filter, if
they have any, works. The patch I posted is a fix that works with what
mac80211 expects -- beacons. The way I'm inclined to resolve this
properly in mac80211 is so that we tell drivers to enable beacons in
STA mode (if it supports this, HW_CAP flag I guess) only after we miss
a probe reply, or while we are scanning, that way we can also listen
for beacons in case we want to roam away to another AP. Just throwing
some ideas out there. Any comments?

  Luis

Re: No ProbeResp - assume out of range

[Kalle Valo]

Luis R. Rodriguez <mcgrof@gmail.com> writes:

> I posted a patch which enables beacons to be received by the STA --
> this however, as was pointed out by the patch that disabled the beacon
> filter on ath5k (note not ath9k, but ath9k also had it disabled),
> increases the number of interrupts on the device, as it seems it
> enables beacons not only for the BSSID you are on but for all BSSIDs.
> Not sure what other devices support and how their beacon filter, if
> they have any, works.

There are beacon filter implementations, for example stlc4560 works
such that it doesn't send any beacons to the host but sends an event
whenever it cannot here beacons anymore.

> The patch I posted is a fix that works with what mac80211 expects --
> beacons. The way I'm inclined to resolve this properly in mac80211
> is so that we tell drivers to enable beacons in STA mode (if it
> supports this, HW_CAP flag I guess) only after we miss a probe
> reply, or while we are scanning, that way we can also listen for
> beacons in case we want to roam away to another AP. Just throwing
> some ideas out there. Any comments?

I and Johannes discussed about this earlier:

http://marc.info/?l=linux-wireless&m=122441202315681&w=2

It should be fairly trivial to implement as a first step, we can
improve it as we learn more.

-- 
Kalle Valo