> >> Can you tell me, if the TCP length is advertised as 73 characters, > >> will tcpdump -X just print out 73 characters, or it will it pad to a > > > 74th? > > > >You might want to try running tcpdump with the "-e" flag; it should > >cause tcpdump to print the length of the packet, as reported to it by > >libpcap. If that's 74 plus the link-layer header size, then either > > OK, I've tried this. If I'm reading this correctly, it turns out to > be 88! According to my references, there should be 22 bytes for an > ethernet header,
14 bytes - 6 bytes of destination address, 6 bytes of source address, and 2 bytes of type. > and 4 bytes for the trailer Only if the frame is less than the minimum Ethernet frame size, which is 60 bytes of header+data. There's a 4-byte CRC at the end of Ethernet frames, but that's typically stripped off by the time it gets to libpcap. 74 plus 14 is, indeed, 88, and, sure enough: > Here's a sample packet (based on the statement tcpdump -vvv -s 0 -X > -i en0 -e tcp and host mail.millikin.edu): > > 15:49:24.365662 0:50:8b:95:4b:36 0:30:65:6e:bd:ee ip 88: > mail.millikin.edu.pop3 > math.millikin.edu.50865: P [tcp sum ok] the Ethernet frame in question is 88 bytes long. > 1:34(33) ack 1 win 6144 (DF) (ttl 128, id 55847, len 73) > 0x0000 4500 0049 da27 4000 8006 c63c ac10 0113 E..I.'@....<.... > 0x0010 ac10 0117 006e c6b1 c7a5 3ba7 b16f 2399 .....n....;..o#. > 0x0020 5018 1800 cbe3 0000 2b4f 4b20 4772 6f75 P.......+OK.Grou > 0x0030 7057 6973 6520 504f 5033 2073 6572 7665 pWise.POP3.serve > 0x0040 7220 7265 6164 790d 0a65 r.ready..e > > The ip packet size is 73 (0x49), but tcpdump, as you can see, is > displaying 74 characters. Tcpdump is displaying the Ethernet payload, i.e. the 74 bytes after the 12-byte header. The code that dumps the packet contents in tcpdump is in the routine that handles the link-layer header; it prints the link-layer header, if the "-e" flag is specified, and then figures out what the next routine to call is (the IP print routine, in this case) and calls it; if there's no such routine, and neither the "-x", "-X", nor "-q" flag was specified, the data after the link-layer header is printed. After all that's done, if the "-x" or "-X" flag *was* specified, the data after the link-layer header is printed. I'm not sure why that code prints only the data after the link-layer header. I can see why the code that handles unknown packet types (e.g., packets with an Ethernet type field that specifies a protocol for which tcpdump doesn't have a print routine) by printing only the stuff after the link-layer header - it can't print a dissected version of that stuff, so it just dumps it - but the code to handle the "-x" and "-X" flags prints the data if one of those flags is set, regardless of whether the packet could be dissected or not, and, if the user specified one of those flags, I'm not sure there's any reason to assume that they didn't want to see the link-layer header dumped out as raw data. If it did that, it would've dumped 88 bytes, and perhaps it'd have been less surprising - at least after you'd run it with "-e". Now, why the Ethernet-layer packet is 88 bytes rather than 87 bytes is another matter; I have no idea why that's the case. Perhaps whatever machine sent it padded it to 88 bytes, or perhaps the code on your machine that *received* the packet rounded its length up to an even number, so that the size, as supplied to libpcap by BPF, was 88 bytes rather than 87 bytes. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
