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