Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2006 18:53:51 -0800
From:      Sam Leffler <sam@errno.com>
To:        Lamont Granquist <lamont@scriptkiddie.org>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: ath0 issue
Message-ID:  <455BD2BF.3050802@errno.com>
In-Reply-To: <Pine.GSO.4.60.0611121455590.29754@sploit.scriptkiddie.org>
References:  <Pine.GSO.4.60.0611112035320.27030@sploit.scriptkiddie.org> <Pine.GSO.4.60.0611121126390.29168@sploit.scriptkiddie.org> <45578B48.1090704@errno.com> <Pine.GSO.4.60.0611121455590.29754@sploit.scriptkiddie.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Lamont Granquist wrote:
> 
> 
> On Sun, 12 Nov 2006, Sam Leffler wrote:
>> 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
> 
> during one of the period where tx was blocking i got ifconfigs that
> looked like:
> 
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255
>         ether 00:09:5b:c8:78:9c
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>         status: associated
>         ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c
>         authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst
>         dtimperiod 1 bintval 100
> 
> ath0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 192.168.70.1 netmask 0xffffff00 broadcast 192.168.70.255
>         ether 00:09:5b:c8:78:9c
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>         status: associated
>         ssid lamontnet channel 1 bssid 00:09:5b:c8:78:9c
>         authmode OPEN privacy OFF txpowmax 30 bmiss 7 protmode CTS burst
>         dtimperiod 1 bintval 100
> 
>> 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
> 
> i'm not certain how to go about collecting that information, but this is
> a very lightly used wireless network with only the freebsd box and the
> windows machine participating and the traffic is limited to the ssh
> sessions that i setup and the usual windoze and dhcp chatter...
> 
>> 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.
> 
> i've only got the two wireless points right now, so i can't get a third
> machine up to sniff...
> 
>> More useful information can be found in the
>> statistics collected by the driver (use athstats).
> 
> here's a before and after of athstats which brackets one of these events:
> 
> warez# ./athstats
> 2243 data frames received
> 2925 data frames transmit
> 50 tx frames with an alternate rate
> 947 long on-chip tx retries
> 115 tx failed 'cuz too many retries
> 2M current transmit rate
> 982 tx management frames
> 6 tx frames discarded prior to association
> 242 tx frames with no ack marked
> 2828 tx frames with short preamble
> 2439 rx failed 'cuz of bad CRC
> 28137 rx failed 'cuz of PHY err
>     19620 OFDM timing
>     8517 CCK timing
> 150622 beacons transmitted
> 534 periodic calibrations
> 16 rssi of last ack
> 19 avg recv rssi
> -96 rx noise floor
> 1 cabq frames transmitted
> 33 switched default/rx antenna
> Antenna profile:
> [1] tx     1862 rx     6345
> [2] tx     1927 rx     6371
> warez# ./athstats
> 2252 data frames received
> 2937 data frames transmit
> 50 tx frames with an alternate rate
> 947 long on-chip tx retries
> 115 tx failed 'cuz too many retries
> 2M current transmit rate
> 982 tx management frames
> 6 tx frames discarded prior to association
> 242 tx frames with no ack marked
> 2840 tx frames with short preamble
> 2440 rx failed 'cuz of bad CRC
> 28145 rx failed 'cuz of PHY err
>     19623 OFDM timing
>     8522 CCK timing
> 150659 beacons transmitted
> 535 periodic calibrations
> 22 rssi of last ack
> 22 avg recv rssi
> -96 rx noise floor
> 1 cabq frames transmitted
> 33 switched default/rx antenna
> Antenna profile:
> [1] tx     1874 rx     6371
> [2] tx     1927 rx     6371
> 
> 

Snapshots are rarely useful; try running athstats 1 and correlate what
you see with pauses.  Another possible reason for deferred operation is
something else in the system blocking the taskq threads; that's a bit
trickier to diagnose.

	Sam



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?455BD2BF.3050802>