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: Jason House <jhouse@xxxxxxxxx>
Date: Sat, 09 Nov 2002 17:22:14 +0000
Maybe I was running an old version.  If everything works, then great... I'll make
sure to update my copy :)

Guy Harris wrote:

> 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.