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?
Bill Caroselli wrote:
Is there any documentation on parsing through the tcpdump header?
There is quite a lot on the web.
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
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?
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?
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?