Re: Problems running ath with bgscan enabled

> Date: Sun, 21 Oct 2007 19:38:56 -0700
> From: Sam Leffler <samerrno.com>
> Sender: owner-freebsd-mobilefreebsd.org
> 
> AT Matik wrote:
> > On Saturday 20 October 2007 22:30:32 Kevin Oberman
wrote:
> >   
> >> My bgscan interval was the default 300 and
almost every 5 minutes I
> >> would lose connectivity, often for over a
minute. When I made the
> >> association between the bgscan interval and
the drop-outs, I did an
> >> "ifconfig ath0 -bgscan" and things
stabilized immediately. No further
> >> problems.
> >>
> >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212,
RF5111, RF5112, RF2413, RF5413)
> >> ath0: <Atheros 5212> mem
0xb4000000-0xb400ffff irq 11 at device 2.0 on
> >> pci11 ath0: mac 5.9 phy 4.3 radio 3.6
> >>
> >> This is really not acceptable for default
behavior as it won't be clear
> >> to many how to fix it. Is it expected or is
something wrong?
> >>
> >>     
> >
> > I believe it is so but as you already did, when
you like to associate only to 
> > the AP of your wpa config you should set -bgscan
and eventually 'roaming 
> > manual' also, if I am not wrong this is described
in ifconfig's manpage
> >
> >   
> 
> wpa_supplicant works fine w/ bgscan.  When the bgscan's
complete 
> wpa_supplicant receives an event and retrieves the scan
results.  It 
> then decides whether or not to roam.  There is no need
to manually 
> configure the device.
> 
> OTOH the scanning+roaming code in wpa_supplicant is
very simplistic and 
> I don't have a lot of experience with how well it does
roaming.  I 
> believe it will only join ap's that are listed in the
config file so it 
> shouldn't roam arbitrarily.  Without a log it's
virtually impossible to 
> comment on reports/complaints.  And even w/ a
wpa_supplicant log it's 
> also useful to understand if there are other events
that trigger 
> scanning and/or roaming--like beacon miss events. 
Hence the need for 
> logs and statistics.

Exactly what statistics should I be collecting? I am
assuming scan, but
is there anything else? assoc? Or is there some other
statistic you need?
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley
Lab)
E-mail: obermanes.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3
987B 3751

Kevin Oberman wrote:
>> Date: Sun, 21 Oct 2007 19:38:56 -0700
>> From: Sam Leffler <samerrno.com>
>> Sender: owner-freebsd-mobilefreebsd.org
>>
>> AT Matik wrote:
>>     
>>> On Saturday 20 October 2007 22:30:32 Kevin
Oberman wrote:
>>>   
>>>       
>>>> My bgscan interval was the default 300 and
almost every 5 minutes I
>>>> would lose connectivity, often for over a
minute. When I made the
>>>> association between the bgscan interval and
the drop-outs, I did an
>>>> "ifconfig ath0 -bgscan" and
things stabilized immediately. No further
>>>> problems.
>>>>
>>>> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212,
RF5111, RF5112, RF2413, RF5413)
>>>> ath0: <Atheros 5212> mem
0xb4000000-0xb400ffff irq 11 at device 2.0 on
>>>> pci11 ath0: mac 5.9 phy 4.3 radio 3.6
>>>>
>>>> This is really not acceptable for default
behavior as it won't be clear
>>>> to many how to fix it. Is it expected or is
something wrong?
>>>>
>>>>     
>>>>         
>>> I believe it is so but as you already did, when
you like to associate only to 
>>> the AP of your wpa config you should set
-bgscan and eventually 'roaming 
>>> manual' also, if I am not wrong this is
described in ifconfig's manpage
>>>
>>>   
>>>       
>> wpa_supplicant works fine w/ bgscan.  When the
bgscan's complete 
>> wpa_supplicant receives an event and retrieves the
scan results.  It 
>> then decides whether or not to roam.  There is no
need to manually 
>> configure the device.
>>
>> OTOH the scanning+roaming code in wpa_supplicant is
very simplistic and 
>> I don't have a lot of experience with how well it
does roaming.  I 
>> believe it will only join ap's that are listed in
the config file so it 
>> shouldn't roam arbitrarily.  Without a log it's
virtually impossible to 
>> comment on reports/complaints.  And even w/ a
wpa_supplicant log it's 
>> also useful to understand if there are other events
that trigger 
>> scanning and/or roaming--like beacon miss events. 
Hence the need for 
>> logs and statistics.
>>     
>
> Exactly what statistics should I be collecting? I am
assuming scan, but
> is there anything else? assoc? Or is there some other
statistic you need?
>   
You said bgscan was causing interruptions in service.  To
diagnose why 
you need to see whether you are not re-joining the same ap
for some 
reason.  This can possibly happen because wpa_supplicant
decides to roam 
(or net80211 in case you are not using wpa_supplicant) or
because some 
event occurs to trigger a scan (e.g. a beacon miss).  A
wpa_supplicant 
log would likely be a first place to start.  Past that you
can turn on 
scan+roam debug msgs in net80211 w/ wlandebug.  Otherwise
you should 
look for beacon miss events that can trigger net80211 state
changes; 
these are shown with wlandebug +state.  Everything that you
can observe 
with in-kernel debugging should also be counted in a
statistic reported 
by wlanstats.  So, as I said, you can either collect logs or
you should 
be able to collect stats to help see what is happening. 
Sometimes stats 
are insufficient and you need logs.

Diagnosis at the driver level is usually warranted only if
you cannot 
see what you need at the higher levels.  Remember that
turning on too 
much debug info can affect realtime behaviour and alter
operation of the 
system.

FWIW my typical test for bgscan is to do something like
this:

1. associate to an ap
2. ping host on the wired side of the ap
3. wait for bg scan to kick in

If things are working correctly you should see no lost ping
packets.  
You will see a short spike in the rtt for ping packets but
bgscan should 
either be canceled or suppressed so long as there is network
traffic.

    Sam

_______________________________________________
freebsd-mobilefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile

To unsubscribe, send any mail to
"freebsd-mobile-unsubscribefreebsd.org"

On Tuesday 23 October 2007 14:30:07 Sam Leffler wrote:
> Kevin Oberman wrote:
> >
> > Exactly what statistics should I be collecting? I
am assuming scan, but
> > is there anything else? assoc? Or is there some
other statistic you need?
>
> You said bgscan was causing interruptions in service. 
To diagnose why
> you need to see whether you are not re-joining the same
ap for some
> reason.  This can possibly happen because
wpa_supplicant decides to roam
> (or net80211 in case you are not using wpa_supplicant)
or because some
> event occurs to trigger a scan (e.g. a beacon miss).  A
wpa_supplicant
> log would likely be a first place to start.  Past that
you can turn on
> scan+roam debug msgs in net80211 w/ wlandebug. 
Otherwise you should
> look for beacon miss events that can trigger net80211
state changes;
> these are shown with wlandebug +state.  Everything that
you can observe
> with in-kernel debugging should also be counted in a
statistic reported
> by wlanstats.  So, as I said, you can either collect
logs or you should
> be able to collect stats to help see what is happening.
 Sometimes stats
> are insufficient and you need logs.
>
> Diagnosis at the driver level is usually warranted only
if you cannot
> see what you need at the higher levels.  Remember that
turning on too
> much debug info can affect realtime behaviour and alter
operation of the
> system.
>
> FWIW my typical test for bgscan is to do something like
this:
>
> 1. associate to an ap
> 2. ping host on the wired side of the ap
> 3. wait for bg scan to kick in
>
> If things are working correctly you should see no lost
ping packets.
> You will see a short spike in the rtt for ping packets
but bgscan should
> either be canceled or suppressed so long as there is
network traffic.
>


well, do you know about the stumbler from net80211 tools
which asks for 
wlan_scan_monitor loading manually but this thing seems
vanished? 

Then I like to add, I guess you won't like it so much but I
have abandoned 
ath_rate_sample but I'm trying it from time to time

Reason is  that ath_rate_sample suddenly disconnect and it
needs a pretty long 
time to come back (either in a/b/g), so I guess Kevin's WPA
thing might 
suffer same.

   
Sometimes it can be forced with "ifconfig ath ssid
whatever up" or sometimes 
adding mode. Specially in 11b environments with
ath_rate_sample the card 
suddenly tries 11g and get disconnected, even when 11b was
set. Sometimes it 
does not come back at all and only a reboot solves it so I
guess something at 
hal level wrong? This last thing is happening only with 7
and I never had it 
with releng_6

The disconnect happens normally after a beacon miss and
sometime in idle state 
when the noise level goes up or when the AP is more busy and
does not respond 
as usual

releng_6 is kind more stable but 7 is really nervous and get
me off n times a 
day, with _onoe I stay always connected and get higher
throughput any time.



Joćo







A mensagem foi scaneada pelo sistema de e-mail e pode ser
considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.ma
tik.com.br
_______________________________________________
freebsd-mobilefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile

To unsubscribe, send any mail to
"freebsd-mobile-unsubscribefreebsd.org"

AT Matik wrote:
> On Tuesday 23 October 2007 14:30:07 Sam Leffler wrote:
>> Kevin Oberman wrote:
>>> Exactly what statistics should I be collecting?
I am assuming scan, but
>>> is there anything else? assoc? Or is there some
other statistic you need?
>> You said bgscan was causing interruptions in
service.  To diagnose why
>> you need to see whether you are not re-joining the
same ap for some
>> reason.  This can possibly happen because
wpa_supplicant decides to roam
>> (or net80211 in case you are not using
wpa_supplicant) or because some
>> event occurs to trigger a scan (e.g. a beacon
miss).  A wpa_supplicant
>> log would likely be a first place to start.  Past
that you can turn on
>> scan+roam debug msgs in net80211 w/ wlandebug. 
Otherwise you should
>> look for beacon miss events that can trigger
net80211 state changes;
>> these are shown with wlandebug +state.  Everything
that you can observe
>> with in-kernel debugging should also be counted in
a statistic reported
>> by wlanstats.  So, as I said, you can either
collect logs or you should
>> be able to collect stats to help see what is
happening.  Sometimes stats
>> are insufficient and you need logs.
>>
>> Diagnosis at the driver level is usually warranted
only if you cannot
>> see what you need at the higher levels.  Remember
that turning on too
>> much debug info can affect realtime behaviour and
alter operation of the
>> system.
>>
>> FWIW my typical test for bgscan is to do something
like this:
>>
>> 1. associate to an ap
>> 2. ping host on the wired side of the ap
>> 3. wait for bg scan to kick in
>>
>> If things are working correctly you should see no
lost ping packets.
>> You will see a short spike in the rtt for ping
packets but bgscan should
>> either be canceled or suppressed so long as there
is network traffic.
>>
> 
> 
> well, do you know about the stumbler from net80211
tools which asks for 
> wlan_scan_monitor loading manually but this thing seems
vanished? 

wlan_scan_monitor never existed.  The complaint about the
module not
being present needs to be removed; it's a noop (there is no
scanning in
monitor mode, you must fix the channel).

> 
> Then I like to add, I guess you won't like it so much
but I have abandoned 
> ath_rate_sample but I'm trying it from time to time

You're free to do what you want.  Every test I've done shows
sample
superior to either of the alternatives.  In particular I've
run
waterfall tests on a wired testbed with all 3 ath rate
control
algorithms and sample is easily the best of the lot.

> 
> Reason is  that ath_rate_sample suddenly disconnect and
it needs a pretty long 
> time to come back (either in a/b/g), so I guess Kevin's
WPA thing might 
> suffer same.

"suddenly disconnects" means nothing to me.

> 
>    
> Sometimes it can be forced with "ifconfig ath ssid
whatever up" or sometimes 
> adding mode. Specially in 11b environments with
ath_rate_sample the card 
> suddenly tries 11g and get disconnected, even when 11b
was set. Sometimes it 
> does not come back at all and only a reboot solves it
so I guess something at 
> hal level wrong? This last thing is happening only with
7 and I never had it 
> with releng_6

sample uses only negotiated rates; what you describe makes
no sense but
w/o real information there's little more one can say. 
However there was
a bug in sample for a few days (maybe >1 week) that
caused it to use
incorrect rate indices but I fixed that; maybe that is what
you're
describing (there would have been a console msg about a
bogus rate idx).

> 
> The disconnect happens normally after a beacon miss and
sometime in idle state 
> when the noise level goes up or when the AP is more
busy and does not respond 
> as usual
> 
> releng_6 is kind more stable but 7 is really nervous
and get me off n times a 
> day, with _onoe I stay always connected and get higher
throughput any time.

Sorry but this really doesn't give me anything to go on and
at this time
I don't have time to chase anything but very specific
issues.  The time
to bring up vague concerns like this was many months ago.

	Sam
_______________________________________________
freebsd-mobilefreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile

To unsubscribe, send any mail to
"freebsd-mobile-unsubscribefreebsd.org"