Re: Are all traces captured by dag card in "tcpdump"

[Guy Harris <guy () alum mit edu>]

On Jun 4, 2004, at 1:09 PM, ice ice wrote:

> here is more information about tcpdump's output:
>
> % tcpdump -c 5 -n tcp -r 20020814-090000-0-anon.pcap.gz
>
> 11:00:00.000058 69.245.49.10.2082 > 143.173.237.247.1214: . 
> 2133229289:2133230749(1460) ack 6821225 win 17188 (DF)
> 11:00:00.000069 236.179.225.218.47302 > 241.46.188.127.www: . ack 
> 3266262189 win 17520 <nop,nop,timestamp[|tcp]> (DF)
> 11:00:00.000083 3.3.241.136.10646 > 252.224.52.109.1469: P 
> 1396830536:1396830556(20) ack 446314422 win 9660 (DF)
> 11:00:00.000097 3.3.241.136.10646 > 252.224.52.109.1469: . 
> 4294965916:0(1380) ack 1 win 9660 (DF)
> 11:00:00.000102 3.3.241.136.10646 > 252.224.52.109.1469: . 
> 4294964825:4294965916(1091) ack 1 win 9660 (DF)
>
> these output seems ok to me,
> so can I assume that the tcpdump can recognize the trace correctly?

It appears so.  I.e., it probably really *is* a Cisco HDLC capture.

> If so, that means the 48 byte is a correct number?

It means that the snapshot length being equal to the payload length of 
an ATM cell does not imply that the capture is an ATM capture; I have 
no idea why the snapshot length was 48, though - perhaps that's what 
the DAG card supplied.

It does *NOT* mean that every packet is 48 bytes long, however.

> So I guess I can just cast the following 40 bytes into what ever 
> (TCP/UDP...) header it indicates.

What "following 40 bytes"?

The packets will have:

        1) a 4-byte link-layer header;

        2) some number of bytes of payload.

The total number of bytes, *including* the 4-byte link-layer header, is 
the "caplen" value from the "pcap_pkthdr" supplied to the callback 
routine for "pcap_dispatch()" or "pcap_loop()" or "pcap_next()" or 
"pcap_next_ex()" ("pcap_next_ex()" is available only in libpcap 0.8 and 
later).  If that value is > 4, then the number of bytes of payload is 
that value minus 4.

If the last two bytes of the 4-byte link-layer header, when treated as 
a big-endian number (i.e., don't just fetch it as a 2-byte integer - 
you'll get the wrong value on a little-endian machine, and note that 
x86-based PC's are little-endian machines) is equal to 0x0800, then the 
payload begins with an IP header.  As the snapshot length is > 24, the 
snapshot length will preserve the fixed-length portion of the IP 
header, but note that if there are IP options, the header could be 
larger than 20 bytes.  Note also that there might be something *other* 
than the snapshot length that caused the entire header not to be 
present, so you should really check the "caplen" value.

If it's present in the header (i.e., "caplen" is large enough to say 
it's there), use the protocol number field from the IP header to 
determine what type of header the IP payload begins with.  Use the  
"header length" field of the IP header to determine where the IP 
payload begins; do *NOT* assume that the IP header is 20 bytes long.  
(If the header length is *less* than 20 bytes long, that's an error; 
you should check for that.)

Also, note that the IP header has a "total length" field.  The length 
of the IP payload is that value minus the IP header length - but if 
that value is greater than "caplen" minus (4 + IP header length), use 
"caplen" minus (4 + IP header length) instead.

> btw, to my understanding that I can not change tcpdump's output format,

You can't do it without changing tcpdump - but you might want to use 
tcpdump as the basis for your program, as all the stuff I describe 
above, including handling multiple types of link-layer header, is 
already done by tcpdump, so you don't have to reinvent the wheel (or 
reinvent the flat tire by just crudely casting the packet data to an 
IP+TCP headeer or something such as that).

> I am currently reading the source code of tcpdump and try to figure 
> out the way to
> parse through the packets. I am wondering whether there is some simple 
> sample programs
> I can read or use in analyzing the pacekts?

There's a limit to how "simple" a correct program can be; a correct 
program has to worry about the stuff I described above - there might be 
simple sample programs out there, but they might do something incorrect 
such as assuming the packet starts with a 14-byte Ethernet header (true 
only if the link-layer type of the capture is DLT_EN10MB), or that 
after the link-layer header is a 20-byte IP header (true only if the 
link-layer header says it's an IPv4 packet *AND* the IP header length 
is 20 bytes) or that after the IP header is a 20-byte TCP header (true 
only if the IP header says it's a TCP packet *AND* there are no TCP 
options).

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.