Re: [ethereal-dev] tcpdump file != ethereal file ?

[Guy Harris <gharris@xxxxxxxxxxxx>]

> Did anyone else see this behaviour ? (in other protocolls ?)

I've seen other mail that shows, for some as-yet-unknown reason, what
appears to be differences in the packet-capture behavior of "tcpdump"
and Ethereal; the odd thing is that both programs are using the "pcap"
library to do the capture and to write out the capture file....

The ones I've seen mentioned here seemed to be differences in the
handling of Ethernet packets shorter than the minimum of 60 octets (64
octets minus the 4-octet frame check sequence); I *think* most if not
all of them were seen on Linux systems.  The frame check sequence might
be, in part, involved, although the most recent one before yours (the
zero-length ICMP packet one) was off by more than 4 bytes.

I'll try looking into it.

> What else should I use instead of fd->cap_len to determine the end of the
> packet ?

For packets such as OSPF running atop IP, the IP header has both a total
packet length and an IP header length; "dissect_ip()" sticks the
difference between them, i.e. IP's notion of the payload length, into
"pi.payload", where "pi" is a global variable.  Some of the dissectors
of protocols above IP use that; OSPF probably should, too.