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>