On Mon 08.10.07 13:15, David Boreham wrote:
>
> I discovered that the fast frames option is disabled by default.
I believe it is enabled by default on all cards for which the hal
reports that they do support it. For example on my 5212 it is enabled by
default. Relevant lines in if_ath.c:
#ifdef ATH_SUPERG_FF
ic->ic_ath_cap |= (ath_hal_fastframesupported(ah) ?
IEEE80211_ATHC_FF : 0);
#endif
This check is not repeated when using iwpriv, so I guess in your case
the hal just wrongly reports your card not being able to do fast frames
when it actually can.
This being the default represents an interoperability problem. If you're
running ath5k for instance, which can not yet decode fast frames, you'll
loose all packets delivered as fast frames. When you're transmitting
lots of data and the connection to the AP is good(i guess >=12Mbit),
this might be a lot. When using TCP the congestion mechanism will
probably slow TCP down till ffs aren't used anymore, leaving you with a
poor throughput.
Ergo: If you're using ath5k with a madwifi ap and have low throughput,
try disabling ff on the ap. You can also check with tcpdump for
fast frames which look like this:
15:36:35.521869 06:0b:6b:56:XX:XX (oui Unknown) > 00:0b:6b:4f:XX:XX (oui
Unknown), 802.3, length 1130: LLC, dsap SNAP (0xaa), ssap SNAP (0xaa),
cmd 0x03: oui Unknown (0x00037f), pid Unknown (0x88bd): Unnumbered, ui,
Flags [Command], length 1116
Uli
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
