["Ken Mann" <KMann@xxxxxxxxxxxxxxx>]

>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.