[EMAIL PROTECTED] wrote:
Here is a simple question I had, and just wonder whether you guys run into
the same situation or not.
When I do a tcpdump like this:
->/usr/sbin/tcpdump -n -s 54 -c 200 -w 54-200.bin
which means I need 54 bytes of the packet content. But when I check the
file size, I get 70 bytes for every packet.
If by "check the file size" you mean you divide the file size by the
number of packets, that doesn't give a meaningful number.
For one thing, there's a file header at the beginning of the file, which
is 24 bytes (that's the "extra" 24 bytes), and includes a "magic number"
to identify the file as a packet capture (and to indicate the byte order
of the machine on which the capture was done), and to give information
such as the link-layer type of the device on which you captured.
For another thing, "-s 54" doesn't mean that you necessarily get exactly
54 bytes for each packet. That'd probably be true on Ethernet, where
packets are padded to 60 bytes (64 bytes if the CRC is included, but on
most platforms the CRC isn't supplied in a capture), although if it's
capturing packets being *sent* by the machine running tcpdump, the
packet won't be padded when it's supplied to tcpdump (the padding
happens after that).
For a third thing, there is a per-packet header for each packet, which
is 16 bytes, and includes the packet time stamp, the length of the
packet data, and the actual length of the packet on the network ("-s 54"
means you won't get more than 54 bytes of packet data, but the packet
might have been longer than that).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
