On Oct 23, 2003, at 1:02 PM, Richard Houle wrote:
1 - Ethereal 0.9.15 is not decoding both of the STUN exchanges. our
product sends out a STUN packet from local port x to gw port x. Then
it sends out another STUN packet from local port y to gw port x.
Ethereal is decoding only the first interaction.
Ethereal recognizes UDP packets as STUN packets if
1) they're at least 20 bytes long *AND* you've captured at least 20
bytes of UDP payload (if, for example, you set the snapshot length in
your capture to something that cuts the UDP payload off before 20
bytes, nothing will be recognized as STUN packets);
2) the first two bytes are, in host byte order, 0x0001, 0x0101,
0x0111, 0x0002, 0x0102, or 0x1112;
3) all the bytes that the length from the header says should be there
are there (meaning "captured", so, again, the snapshot length could
break things);
4) the UDP payload isn't any *longer* than that length.
If one of those isn't true, the packet won't be treated as a STUN
packet.
If one of those causes a problem, we might be able to remove the check,
although, as this checking is done for heuristic packet recognition,
meaning we'd check *any* UDP packet for that, a too-loose check could
result in non-STUN packets being recognized as STUN packets.
2- Ethernet has 14 bytes of header and then a 4 byte footer, yes?
Ethernet packets, as they appear on the wire, have 14 bytes of header,
at least 46 bytes of payload, and 4 bytes of CRC.
Ethernet packets, as delivered to the host by a network card, have 14
bytes of header and at least 46 bytes of payload. They might, or might
not, have 4 bytes of CRC, depending on
1) whether the network card has an option to give the CRC to the host
(I don't know which cards do)
and
2) whether, if there is such an option, the driver has enabled it (not
all drivers do; I don't know all the ones that do, but I think some
NetBSD ones and some Mac OS X ones do)
and
3) whether those bytes are made available to the capture mechanism
used by libpcap (the library Ethereal uses to capture packets).
Ethernet packets, as "wrapped around" by the host when your capture
sees a packet being transmitted by the host on which you're doing the
capture, have a 14-byte header, might have even fewer than 46 bytes of
payload (if the wrapping around is done before the packet is padded),
and almost certainly do *NOT* have a CRC, as the CRC is typically
generated by the network card, and the wrapping around is done
independently of the networking card (networking cards typically do
*NOT* supply packets sent through the card as input to the host - I
don't know of any that do).
See also the FAQ on this topic:
http://www.ethereal.com/faq.html#q5.34
*IF* the underlying capture mechanism supplies the FCS (this is not
under the direct control of Ethereal), or you have a capture file from
some non-libpcap-based capture device or program and Ethernet packets
in it contain an FCS, Ethereal 0.9.15 and later should show the FCS.
(The next release fixes some cases where extra crap at the end of
packets that *isn't* an FCS was being shown as an FCS by 0.9.15.)