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>