Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Nov 2006 12:59:52 -0800
From:      Sam Leffler <sam@errno.com>
To:        Lamont Granquist <lamont@scriptkiddie.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: ath0 issue
Message-ID:  <45578B48.1090704@errno.com>
In-Reply-To: <Pine.GSO.4.60.0611121126390.29168@sploit.scriptkiddie.org>
References:  <Pine.GSO.4.60.0611112035320.27030@sploit.scriptkiddie.org> <Pine.GSO.4.60.0611121126390.29168@sploit.scriptkiddie.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Lamont Granquist wrote:
> 
> i did the same thing with running:
> 
> while(1)
>  echo foo
>  sleep 1
> end
> 
> in a window ssh'd into the machine with the ath0 driver, but with the
> kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0xffffffff
> -- there should be packets sent every second while doing this.

Not usually a good idea to enable so much debugging.  The console
printfs will alter operation.

> 
> i saw the same behavior where tx packets would tend to spool up and
> buffer.  here's the output of one second where a bunch of spooled up
> packets were sent alont with the previous second and following second
> and with a note on how long it had been before any ath*tx* routine had
> been called.  hopefully this is useful for debugging -- i've got copious
> amounts of debugging logs, so let me know if i've guessed wrongly about
> what is relevant...
> 
> this is the previous debugging notice for ath*tx* which i believe
> indicates nothing
> sent out on the interface since 11:17:36:

If tx stops in ap mode you need to figure out whether the h/w tx q is
stalled or something else "above" is blocking outbound traffic.  The
usual things to check are:

1. are there resources in the driver to send a packet (e.g. buffers on
the queue); if the tx q is full then the OACTIVE bit will be marked on
the interface and visible with ifconfig
2. if packets are queued to the h/w and not going out then you need to
identify whether a higher priority frame is blocking them; this is
harder but can occur when something like a beacon frame fails to go out
or if there is cabq traffic q'd up behind the beacon frame that doesn't
make it out
3. if none of the above is blocking traffic then h/w may consider the
media busy; this can happen if your ap is operating in a busy
environment and things like protection are being used heavily, or if you
have an overlapping BSS that is operating in 11b

Often problems such as this are most easily understood by sniffing
traffic from another station and looking for traffic patterns coincident
with the event on the ap.  More useful information can be found in the
statistics collected by the driver (use athstats).

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45578B48.1090704>