Thanks for helping, i 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? If so, that means the 48 byte is a correct number? So I guess I can just cast the following 40 bytes into what ever (TCP/UDP...) header it indicates.
btw, to my understanding that I can not change tcpdump's output format, that is why
I want to write my own program reading the trace file, filtering out what I want and
print them out in my own style.
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?
thanks, zs
From: Guy Harris <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
Date: Fri, 4 Jun 2004 11:33:51 -0700
On Jun 4, 2004, at 9:32 AM, ice ice wrote:
Yes, I should say that the trace file is in pcap format.
20020814-090000-0-anon.pcap.gz: tcpdump capture file (little-endian) - version 2.4 (BSD/OS Cisco HDLC, capture length 48)
So I couldn't assume the 48byte header is the normal IP+whatever header even it says Cisco HDLC?
It's not a "48byte header", it's a 48 byte capture length.
However, 48 is a very suspicious number here, given that the CoralReef stuff is ATM-oriented, although I'd expect it to be 53, not 48, if the packets in that capture are ATM cells - it'd probably be pretty silly to supply the cell payload but not the header.
But, no, the header of those packets isn't necessarily just a "normal IP+whatever header". For one thing, there's no guarantee that the packets are IP packets, and, for another thing, there's header information *before* the IP header, namely the link-layer header, and the link-layer header is what would specify whether the packets are IP packets or not. The header of packets isn't necessarily just a normal "IP+whatever header" even with an *Ethernet* (DLT_EN10MB) capture, for the same reasons.
If they're *truly* Cisco HDLC packets - and, if tcpdump can read that capture file, it'd treat it as Cisco HDLC, so it sounds as if they are - the packet format is described in
http://www.nethelp.no/net/cisco-hdlc.txt
(and see also section 4.3.1 of RFC 1547); the packet starts with a four-byte link-layer header with one byte of address, one zero byte, and two bytes containing a protocol type. The protocol types are usually Ethernet protocol types, so 0x0800 would be IP, but Cisco added some additional packet types (see the URL given above).
*IF* the protocol type is 0x0800, after the 4-byte header comes an IP header and IP payload.
All of this is the case *IF* the link-layer type is DLT_C_HDLC (or DLT_CHDLC on some versions of libpcap, but they have the same numerical value). If you're using libpcap to read a capture file, you have to call "pcap_datalink()" to get the link-layer header type for the capture, and interpret the raw packet data based on that - that's what tcpdump does.
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
_________________________________________________________________
Looking to buy a house? Get informed with the Home Buying Guide from MSN House & Home. http://coldwellbanker.msn.com/
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
