>Message: 10 >Date: Sat, 29 Jan 2005
02:47:29 -0800 >From: Guy Harris <gharris@xxxxxxxxx> >Subject: Re: [Ethereal-users] RE: Capture Header Decoding for
Netxray > (NetAsyst) >To: Ethereal user support <ethereal-users@xxxxxxxxxxxx> >Message-ID: <41FB69C1.6090407@xxxxxxxxx> >Content-Type: text/plain; charset=ISO-8859-1;
format=flowed > >Ken Mann wrote: >> The structure below is
what I have come up with. The noise level seems >> to use different
units from the signal strength, 127 = 100%, 0xFF = >> ignore it.
dummy2[2] appears to be set to 5 when the packet is WEP >> encrypted.
The errorFlag value is either 1 or 5 when there is a problem >> with
the packet (either CRC or WEP errors). >> typedef struct >>
{ >> UINT64
pktTimeuSec; >> SINT16
capLen; >> SINT16
pktLen; > >Ethereal currently treats the first of the 16-bit
integers as the actual >length of the packet and the second of them as
the number of bytes >captured (that number can be smaller than the actual
length because of >slicing, or whatever it's called in
Sniffer). > >The names you give them make it sound to me as if the
first of them is >the number of bytes captured and the second is the
actual length, >instead; is that the case? [Ken Mann] I
probably have them backwards. For the software I am writing, they have to be the
same. > >> UCHAR
errorFlag; // 802.11 only > >That doesn't
appear to be 802.11-only - I think we've seen Ethernet >captures where,
if the low-order bit is set, there's a bad FCS. > >Do you happen to
know what the difference between a value of 1 and 5 >here is? Both
of them have the low-order bit set; one but not the other >has 0x4
set. (If you can *generate* Sniffer files that the Sniffer can
>read, it might be interesting to experiment with different bits set in
>this field.) [Ken Mann] No, I simply ignore the packet if this field is
non-zero. Schedules and other priorities don't permit any further
experiments. > >>
UCHAR dummy2[3]; // Appear to always be
zero > >errorFlag and dummy2 could be a 4-byte little-endian flag
word - or they >could be a 1-byte flag and 3 padding bytes, or a 2-byte
little-endian >flag word and 2 padding bytes. (Again, if you can
generate Sniffer >files, it might be interesting to tweak various bits in
dummy2[0-2].) > >> UCHAR
channel; // 802.11
only >> UCHAR
speed; // 802.11
only >> UCHAR signalStrength;// 802.11
only >> UCHAR noiseLevel; //
FF (none reported) or 127 (0x7F) == 100% > >What are the units of
signalStrength? [Ken Mann] The value in the file is the literal Percent
number reported in the packet decode
view. > >Presumably noiseLevel is also
802.11-only. > >> UCHAR
dummy3[4]; // Meaning unknown, can be
zeroed >> UCHAR
srcMac[6]; // 802.11 only > >Is that any
different from the source MAC address in the 802.11 header? [Ken Mann] I
believe it is always the
same.
