Ethereal-dev: Re: [Ethereal-dev] problems with packets inside ICMP

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sat, 9 Nov 2002 01:10:01 -0800
On Thu, Nov 07, 2002 at 06:48:38PM +1100, Ronnie Sahlberg wrote:
> > 1. can't filter on the copy of the packet embedded in the ICMP packet
> >     I wanted to write a filter for fields inside the packet that was
> > bounced (ICMP supplies a copy of the packet in its payload)... I
> > discovered that I could not do so.  There is no way to filter fields
> > that belong to one protocol, but happen to be inside of the tree for
> > another protocol  (ie. the copied IP packet as the ICMP payload).
> >     I remember when I've looked at the filtering code in the past, that
> > a particular subtree was not searched for a filterable field if the
> > subtree was not for the protocol that "owned" that field.  So items like
> > "ip.dst" inside of an icmp packet is not filterable.  The easiest "fix"
> > would make the filtering slower...
> 
> That would be a bug.   I have previously filtered on various fields and this
> have
> still picked up fields in protocols encapsulated inside ICMP.
> Maybe someone has changed something?

It worked for me - matching "udp.dstport == 2049" matched an ICMP
Destination Unreachable in a capture I have, where the ICMP message
included the IP and UDP headers of the unfortunate NFS packet in
question.

> > 2. checksum calculations
> >     The IP checksum was being marked as incorrect, while it was correct
> > in the original packet.  I don't think ICMP modifies the header... I
> > don't know exactly where the problem is, but have not dug down for it
> > either.
> 
> Is the entire original packet encapsulated in the ICMP packet?
> More than likely, your ICMP packet only contains the first few bytes of the
> offending IP
> packet and not the full IP packet. That is why the checksum is incorrect.

You don't need the full IP packet, you just need the IP header - the
checksum only covers the header.

However, if we don't have the full IP header (which is all that's needed
for the checksum, not any of the IP payload), we shouldn't be trying to
compute the checksum in the first place.

The same should apply to any TCP or UDP checksums in the ICMP packet's
payload.  (If not, that's a bug.)

In the capture I referred to above, the packet that matched also has the
IP checksum marked as valid.  The UDP checksum is non-zero, but isn't
checked because the full UDP packet isn't there.