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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
