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
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 <[email protected]> wrote:
> > On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <[email protected]> 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
"Bharat Bhushan" <[email protected]> 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
On Tue, Nov 4, 2008 at 6:17 AM, Michael Buesch <[email protected]> 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 %% http://www.bobcopeland.com
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.
On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <[email protected]> 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
On Sun, Nov 2, 2008 at 2:42 PM, Tomas Winkler <[email protected]> wrote:
> On Mon, Nov 3, 2008 at 12:03 AM, Michael Buesch <[email protected]> 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
Tomas Winkler <[email protected]> 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
On Mon, Nov 3, 2008 at 11:20 PM, Johannes Berg
<[email protected]> 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
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.
2008/11/2 Luis R. Rodriguez <[email protected]>:
> 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
Johannes Berg <[email protected]> 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
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.
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
On Tue, Nov 4, 2008 at 10:19 AM, Christoph Hellwig <[email protected]> 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
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
On Sunday 02 November 2008 23:29:35 Luis R. Rodriguez wrote:
> On Sun, Nov 2, 2008 at 2:03 PM, Michael Buesch <[email protected]> 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.
On Sun, Nov 2, 2008 at 2:03 PM, Michael Buesch <[email protected]> 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