Hi Guy,
My point was that truncation would not be a problem. Not
that truncation could not occur. Most, if anything that is
truncated with a snaplen of 1500 is part of a file xfer or
padding.
Remember, Dario was capturing OSPF. Are you going to tell
me that most OSPF packets are going to exceed 1500 bytes or even come
close?
It just seemed to me that my post was *corrected* due to nit-picking
than an effort to help Dario solve his problem.
Thanks,
Mike
On Mon, Nov 03, 2003 at 04:08:49PM -0800, Guy Harris wrote:
>
> On Nov 3, 2003, at 3:33 PM, MH wrote:
>
> >A snaplen of 1500 is not going to cause truncation problems.
>
> On Ethereal, yes, it will.
>
> I just did a capture with "-s 1500", and did an NFS read while it was
> running.
>
> Many of the NFS packets were 1518 bytes on the wire (1500 bytes of
> payload, 14 bytes of header, and 4 bytes of FCS, because I was
> capturing on a device whose driver supplies the FCS to BPF). Only 14
> bytes of header and 1486 bytes of payload were captured - the full
> payload was no captured.
>
> >He could also specify -s 0 instead of -s 65535 to capture the full
> >packet.
>
> ...if he's using a sufficiently-recent version of tcpdump.
>
> >Older versions of the tcpdump man page even use
> >a snaplen of 1500 in given examples.
>
> Then they either changed the semantics of "-s" (unlikely) or they had a
> bug in the man page (more likely).
>