[Prism54-devel] Re: Active testing rules
Jean-Baptiste Note
jean-baptiste.note at wanadoo.fr
Thu Jan 27 09:50:14 UTC 2005
Hello Feyd, dear list
Feyd <feyd at seznam.cz> said :
> On Wed, 26 Jan 2005 19:29:24 +0100
> Jean-Baptiste Note <jean-baptiste.note at wanadoo.fr> wrote:
>
>>
>> That's because the buffer is aligned (the address is little-endian), and
>> you don't "see" the leading zeroes, but this is seen in many frame
>> types, i'm sure of the meaning. While we're at it, all frames seem to
>> have their size 32-bit aligned ; i'll implement this too.
>
> Ah I see. The 32bit alignment is there probably to allow the "single"
> DMA transfers of the NET2280.
> Of course you are right :) The byte at 48 seems to be the offset.
You're right ! one unknown field has been uncovered :) I'm too lazy to
check, but i guess this is intended to be able to align different parts
of the frame on cache line boundaries (this would explain the difference
between mgmt frames and data frames, because the interesting payload is
not at the same place).
Meanwhile, i've put a basic monitor mode into the driver. It works
rather well in "non-madwifi" mode (debugging remains to be done in
madwifi mode : scanning goes on when it should be stopped. Anyway a
major overhaul of madwifi code will need be done, I didn't put enough
thought in it).
At least looking at the received frames is much nicer in ethereal than
it is looking at dmesg : it makes "active testing" much, much, much
nicer.
One thing frustrating : i don t know how to report the FCS. On all
combinations that i tried, when sending the frame with the FCS, ethereal
interprets it as data, and reports a malformed packet...
Additionally, do you know if ethereal can use the "prism2 header" that
the prism54 pci driver fills in ? -- i can fill most fields too, just
wondering if this is worth my pain :)
JB
--
Jean-Baptiste Note
+33 (0)6 83 03 42 38
jean-baptiste.note at wanadoo.fr
More information about the Prism54-devel
mailing list