tcpdump files

bridged with qdn.public.qnxrtp.applications
Post Reply
Bill Caroselli

tcpdump files

Post by Bill Caroselli » Tue Nov 11, 2003 10:22 pm

I'm collecting Ethernet data using tcpdump. I'm capturing the data to
a file and interpreting the data myself. I've been interpreting the
data from QNX4's netsniff quite successfully. Once I'm found the
Ethernet packet type I'm in business. But the header on tcpdump
records seems to vary in length.

Is there any documentation on parsing through the tcpdump header?

Rennie Allen

Re: tcpdump files

Post by Rennie Allen » Wed Nov 12, 2003 4:39 pm

Bill Caroselli wrote:
Is there any documentation on parsing through the tcpdump header?
There is quite a lot on the web.

Xiaodan Tang

Re: tcpdump files

Post by Xiaodan Tang » Thu Nov 13, 2003 12:36 am

Bill Caroselli <qtps@earthlink.net> wrote in message
news:bornfn$n7e$1@inn.qnx.com...
I'm collecting Ethernet data using tcpdump. I'm capturing the data to
a file and interpreting the data myself. I've been interpreting the
data from QNX4's netsniff quite successfully. Once I'm found the
Ethernet packet type I'm in business. But the header on tcpdump
records seems to vary in length.

Is there any documentation on parsing through the tcpdump header?
Get the libpcap source, and look into "savefile.c" file. FYI, here is the
structures.

struct pcap_file_header {
bpf_u_int32 magic;
u_short version_major;
u_short version_minor;
bpf_int32 thiszone; /* gmt to local correction */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
bpf_u_int32 snaplen; /* max length saved portion of each pkt */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
};

struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};


-xtang

Bill Caroselli

Re: tcpdump files

Post by Bill Caroselli » Thu Nov 13, 2003 1:44 pm

Xiaodan Tang <xtang@qnx.com> wrote:

XT > Get the libpcap source, and look into "savefile.c" file. FYI, here is the
XT > structures.

XT > struct pcap_file_header {
XT > bpf_u_int32 magic;
XT > u_short version_major;
XT > u_short version_minor;
XT > bpf_int32 thiszone; /* gmt to local correction */
XT > bpf_u_int32 sigfigs; /* accuracy of timestamps */
XT > bpf_u_int32 snaplen; /* max length saved portion of each pkt */
XT > bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
XT > };

XT > struct pcap_pkthdr {
XT > struct timeval ts; /* time stamp */
XT > bpf_u_int32 caplen; /* length of portion present */
XT > bpf_u_int32 len; /* length this packet (off wire) */
XT > };


Thank you Xiaodon. This helps a lot.

In all of the packets that I've looked at the 2 lengths (caplen & len)
have been the same. And the both get me to the start of the next
header.

Do I understand correctly that the second one (len) is what a packet
would be if were not fragmented?

Xiaodan Tang

Re: tcpdump files

Post by Xiaodan Tang » Thu Nov 13, 2003 5:36 pm

The "len" seems have some history in it :) It either is the buffer size (if
the file is generated on
non-qnx machine), or same as the caplen (this is a one time bug of
nfm-bpf.so I think), or
represent the real *this* packet length. :-)

-xtang

Bill Caroselli <qtps@earthlink.net> wrote in message
news:bp01sf$png$2@inn.qnx.com...
Xiaodan Tang <xtang@qnx.com> wrote:

XT > Get the libpcap source, and look into "savefile.c" file. FYI, here is
the
XT > structures.

XT > struct pcap_file_header {
XT > bpf_u_int32 magic;
XT > u_short version_major;
XT > u_short version_minor;
XT > bpf_int32 thiszone; /* gmt to local correction */
XT > bpf_u_int32 sigfigs; /* accuracy of timestamps */
XT > bpf_u_int32 snaplen; /* max length saved portion of each
pkt */
XT > bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
XT > };

XT > struct pcap_pkthdr {
XT > struct timeval ts; /* time stamp */
XT > bpf_u_int32 caplen; /* length of portion present */
XT > bpf_u_int32 len; /* length this packet (off wire) */
XT > };


Thank you Xiaodon. This helps a lot.

In all of the packets that I've looked at the 2 lengths (caplen & len)
have been the same. And the both get me to the start of the next
header.

Do I understand correctly that the second one (len) is what a packet
would be if were not fragmented?

Bill Caroselli

Re: tcpdump files

Post by Bill Caroselli » Fri Nov 14, 2003 6:11 pm

I hve found UDP packets where there was a difference. The len field is
what gets me to the start of the next record.

It would appear that when the two fields are different it means that
the packet *should have been* len bytes long but that only caplen bytes
were actually captured. I.E. the tail end of the packet is missing.


Xiaodan Tang <xtang@qnx.com> wrote:
XT > The "len" seems have some history in it :) It either is the buffer size (if
XT > the file is generated on
XT > non-qnx machine), or same as the caplen (this is a one time bug of
XT > nfm-bpf.so I think), or
XT > represent the real *this* packet length. :-)

XT > -xtang

XT > Bill Caroselli <qtps@earthlink.net> wrote in message
XT > news:bp01sf$png$2@inn.qnx.com...
In all of the packets that I've looked at the 2 lengths (caplen & len)
have been the same. And the both get me to the start of the next
header.

Do I understand correctly that the second one (len) is what a packet
would be if were not fragmented?

Post Reply

Return to “qdn.public.qnxrtp.applications”