Here's one for ethereal!
Here is a packet with a TOTALLY incorrect checksum. The "other" trace
program never flagged it as incorrect. Ethereal gives the same malformed
error!
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxx]
Sent: Wednesday, October 30, 2002 12:43 PM
To: Michele Bustos
Cc: 'ethereal-users@xxxxxxxxxxxx'
Subject: Re: [Ethereal-users] extension headers ipv6
On Wed, Oct 30, 2002 at 12:32:17PM -0800, Michele Bustos wrote:
> I have an instance where we are configuring extension headers,
specifically
> routing and hop-by-hop with an ICMPv6 after the extension header.
> Ethereal decodes that same packet with a incorrect checksum (suggested
> correct 0xA3c4)(41924) AND a Malformed Packet ICMPv6. Other vendor's trace
> programs are giving me a GOOD frame indicator and no "bad" flag for the
> checksum (0xA3d3)(41939). My gut is to trust ethereal, however, I have not
> seen it in writing that the checksum of upperlayer protocols when daisy
> chained with IPv6 extension headers is supported. I am trying to force a
> bad checksum on that packet at this time to further investigate.
> Ideas?
Send to the list a capture file containing the packet with the problem,
so some one of us can look at it and see if it's an Ethereal bug or a
problem with the packet. (In recent versions of Ethereal, you can
select a frame, use the "Mark Frame" menu item (or control-M) to mark
the frame, possibly mark more frames in the same fashion, and then use
the "Save only marked packets" option in the "Save As..." dialog box, at
least with some capture file formats - you might have to save in libpcap
format - in order to save selected packets from a capture.)
Without seeing the packet (preferably in a form Ethereal can read, not a
hex dump of the packet data), it's unlikely that we'd be able to figure
out what the problem is.
Attachment:
hhhhhhh.enc
Description: Binary data