Re: IP length vs IP6 length inconsistency (fwd)

[Guy Harris <guy () alum mit edu>]

On Sep 13, 2007, at 11:14 PM, Pekka Savola wrote:

> On Thu, 13 Sep 2007, Guy Harris wrote:
> > > There are differences as to how next-headers are chained in v4 vs  
> > > v6. but I'd be tempted to argue that a uniform representation  
> > > would be helpful.
> > > Is this inconsistency intentional?
> >
> > If the intent is to display the raw value of the length fields in  
> > the headers, then, yes, it is, as the meanings of the length fields  
> > differ.
>
> Well, I guess someone needs to decide what the intent is :-).

That's why I phrased it that way. :-)  I.e., I can see both sides of  
the argument, and either choice would work for me.

Anybody else want to weigh in?

> If the intent is to print the raw contents, it'd be helpful if the  
> names of the fields printed were different.

Yup - it should distinguish between "total length" and "payload length".

> Another related problem: tcpdump expressions such as 'less 100'  
> cause similar inconsistency confusion.  It seems the length there  
> includes the L2 headers as well, even though the man page speaks of  
> 'packet length' (instead of say, frame length).  I wonder if this  
> also is intentional?

Probably - there's a BPF instruction to get the raw length of the  
packet.

However, "raw length of the packet" means "amount of data handed to  
bpf_filter()", which means that it includes the length of any "pseudo- 
header" prepended to the packet, such as the Prism or AVS or radiotap  
header for 802.11 packets, or the pseudo-header supplied by SunATM,  
or....

The man page should be changed to reflect that.

> E.g.:  I have router advertisements whose IP length (header+payload)  
> is 104 bytes (with -e, ethernet length is 118 bytes).  The first  
> value I can see them is with 'less 118' (instead of 'less 104').  So  
> there seems to be an offset of about 14 bytes here.

...at least on Ethernet.

>  Second example are ARP requests/replies whose L2 length is 60  
> bytes.  They can be seen with 'less 60' but no longer with 'less 59'.

...and "60 bytes" includes the padding.

Oh, and it's probably *64* bytes if the network adapter and driver  
supply the CRC (as is the case, for example, on the machine and OS on  
which I'm typing this).

I.e., if you want to filter packets based on the IPv4 length, you  
should just fetch the length from the IPv4 header using ip[2:2] (and  
do the equivalent for IPv6); doing that by looking at the link-layer  
length is a nuisance at best, and a royal pain at worst.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.