2009/2/23 <pat-l...@erley.org>: > On Mon, 23 Feb 2009 18:03:16 +0200, Nick Kossifidis <mickfl...@gmail.com> > wrote: >> 2009/2/23 Bob Copeland <m...@bobcopeland.com>: >>> On Mon, 23 Feb 2009 00:20:50 +0100, Jiri Slaby wrote >>>> On 22.2.2009 22:56, Jiri Slaby wrote: >>>> > Well, maybe we should try to reproduce with jumbo packets sent to the >>>> > ath5k receiver, since I think it (1) is not very much test-covered >>>> > code >>>> > (2) appears to be related. >>>> >>>> According to the spec I have for older chip, there is not `done' flag >>>> set for descriptors which have `more' flag set. We handle this wrongly. >>>> Am I looking correctly, Nick, Luis, Bob? >>>> >>>> I still don't see what could have caused this though. >>> >>> As I understand it, yes, we don't do the right thing when the more flag >>> is set. We're supposed to keep processing packets until we get one with >>> the done flag, and then all of that is supposed to be merged into a >>> single >>> packet. Other flags such as the rx rate are only valid on the final >>> packet. >>> >>> However, I did some debugging of this a while ago and concluded that the >>> 'jumbo' frames were largely garbage data. The dma buffer size is >>> certainly >>> large enough for a standard 802.11 frame and the 'more' flag is only >>> supposed to be set if the dma buffer size is too small for a packet. In >>> all cases the dma buffer size was 2500+ bytes and the actual contents of >>> the packets looked like random values (I did have encryption turned on, >>> but there were no 802.11 headers I could see.) >>> >>> So I am not sure if the jumbo packets are causing bad things to happen, >>> or if they are an indication that something bad has already happened. >>> >> >> Hmm can someone test ath5k against an Atheros AP using fast frames ? >> Maybe they are jumbo frames but they don't have any header etc so that >> they look like one frame after un-fragmentation, documentation says >> that the current frame is continued in the next descriptor if more is >> set to 1 so i guess next buffer might not have the header. If more = 0 >> then it's our last descriptor and only then other fields such as done, >> frame receive ok, rssi etc are valid. > > If an ath9k device in AP mode using hostapd counts as an Atheros AP, then I > > can test tonight. If you can send me the steps to test this, I'll do it in > > about 8 hours. > > Pat Erley >
As far as i know ath9k doesn't support fast frames ;-( -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
