On Sat 27.10.07 03:12, Nick Kossifidis wrote: [snip] > About fast frames: actually it's more complicated, we have more > descriptors for each buffer, we have to do encapsulation and > decapsulation (check out madwifi code) by also tweaking the stack etc. > Currently noone is working on fast frames because we have other > priorities (eg. make tests and gather dumps, compare dumps with > current code and fill the gaps etc).
I hacked into the tx function and managed to let the card send out the contents of two descriptors in one frame. I didn't do any encapsulation, I just copied the first packet(an ICMP echo request), fetched a second buffer, called the fill functions appropriately and finally it worked. I checked on the receiving side and the card actually sends out the two segments concatenated. Higher layers do (of course) ignore the second packet, but that would be handled by en-/decapsulation. There's just one problem...I can't send more than 2312 bytes, which also happens to be the limit defined in the 802.11 spec. Or maybe I can, but the receiver(also running ath5k) doesn't accept it...on that side I hacked into the rx tasklet and it doesn't get anything above 2312 :( Sooo...any ideas? I guess there's some flag like "large frame" missing in the transmit descriptor. Unfortunately, I can't check with madwifi cause it only does FF in managed mode and I don't think we have an AP that can do that. Guess I'll have to tweak it to do it in ad-hoc mode also...otherwise it'd be damn easy since it spits out the descriptors with "athdebug +xmit". Uli _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
