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

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.60.0611121455590.29754>