Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
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-09-0-anon.pcap.gz
11:00:00.58 69.245.49.10.2082 > 143.173.237.247.1214: .
2133229289:2133230749(1460) ack 6821225 win 17188 (DF)
11:00:00.69 236.179.225.218.47302 > 241.46.188.127.www: . ack
3266262189 win 17520 (DF)
11:00:00.83 3.3.241.136.10646 > 252.224.52.109.1469: P
1396830536:1396830556(20) ack 446314422 win 9660 (DF)
11:00:00.97 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.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
Thanks for helping, i here is more information about tcpdump's output: % tcpdump -c 5 -n tcp -r 20020814-09-0-anon.pcap.gz 11:00:00.58 69.245.49.10.2082 > 143.173.237.247.1214: . 2133229289:2133230749(1460) ack 6821225 win 17188 (DF) 11:00:00.69 236.179.225.218.47302 > 241.46.188.127.www: . ack 3266262189 win 17520 (DF) 11:00:00.83 3.3.241.136.10646 > 252.224.52.109.1469: P 1396830536:1396830556(20) ack 446314422 win 9660 (DF) 11:00:00.97 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-09-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.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
On Jun 4, 2004, at 9:32 AM, ice ice wrote: Yes, I should say that the trace file is in pcap format. 20020814-09-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.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
Hi, Yes, I should say that the trace file is in pcap format. 20020814-09-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? thx From: Stephen Donnelly <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump" Date: Fri, 04 Jun 2004 14:45:25 +1200 ice ice wrote: I have a trace saying "Data provided by WAND Research Group using the dag interface card OC48 data analysis required CAIDA's CoralReef software suite." I am confused by the statement of "OC48 data analysis required CAIDA's CoralReef software suite". It seems to me that traces captured by dag card are collections of packet headers. And I can use Tcpdump or CoralReef libary in reading the packet information from the trace. And I even can directly read header by header (IP+TCP/UDP/or other+..) from the trace by my own program, and interpret the information in packet by matching the structure specified in RFC. Then why "OC48 data analysis required CAIDA's CoralReef software suite"? I apply the tcpdump on the trace, it also can print out the packet information. But when I write my own program to parse through the trace, I can not get right information. Why is that? If tcpdump can parse the file, there is a good chance it is in 'libpcap' format. You can tell easily by running 'file yourfilename', e.g. $ file /usr/var/tmp/foo.pcap /usr/var/tmp/foo.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 68) DAG cards have their own native format as well, but the research group may have converted the traces to libpcap format for public convienience. Perhaps they did this using CoralReef. How are you attempting to parse it if you are having trouble? Note you shouldn't assume it uses DLT_EN10MB. Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. _ MSN 9 Dial-up Internet Access fights spam and pop-ups now 3 months FREE! http://join.msn.click-url.com/go/onm00200361ave/direct/01/ - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Are all traces captured by dag card in "tcpdump"
ice ice wrote: I have a trace saying "Data provided by WAND Research Group using the dag interface card OC48 data analysis required CAIDA's CoralReef software suite." I am confused by the statement of "OC48 data analysis required CAIDA's CoralReef software suite". It seems to me that traces captured by dag card are collections of packet headers. And I can use Tcpdump or CoralReef libary in reading the packet information from the trace. And I even can directly read header by header (IP+TCP/UDP/or other+..) from the trace by my own program, and interpret the information in packet by matching the structure specified in RFC. Then why "OC48 data analysis required CAIDA's CoralReef software suite"? I apply the tcpdump on the trace, it also can print out the packet information. But when I write my own program to parse through the trace, I can not get right information. Why is that? If tcpdump can parse the file, there is a good chance it is in 'libpcap' format. You can tell easily by running 'file yourfilename', e.g. $ file /usr/var/tmp/foo.pcap /usr/var/tmp/foo.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 68) DAG cards have their own native format as well, but the research group may have converted the traces to libpcap format for public convienience. Perhaps they did this using CoralReef. How are you attempting to parse it if you are having trouble? Note you shouldn't assume it uses DLT_EN10MB. Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Are all traces captured by dag card in "tcpdump" format?
Hi, I have a trace saying "Data provided by WAND Research Group using the dag interface card OC48 data analysis required CAIDA's CoralReef software suite." I am confused by the statement of "OC48 data analysis required CAIDA's CoralReef software suite". It seems to me that traces captured by dag card are collections of packet headers. And I can use Tcpdump or CoralReef libary in reading the packet information from the trace. And I even can directly read header by header (IP+TCP/UDP/or other+..) from the trace by my own program, and interpret the information in packet by matching the structure specified in RFC. Then why "OC48 data analysis required CAIDA's CoralReef software suite"? I apply the tcpdump on the trace, it also can print out the packet information. But when I write my own program to parse through the trace, I can not get right information. Why is that? Thanks, zs _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
