On Sat, May 03, 2003 at 12:28:22AM -0400, nak26 wrote:
> I was hoping that since reported length is greater than the actual length,
> ethereal would somehow magically create (add the right byte-difference) a new
> tvb-uffer with a length = reported_length, so that my message dissector would
> not pass the end of the tvb.
Actually, a tvbuff needs more lengths than just the actual and reported
length. There's:
the amount of data in the tvbuff;
the amount of data that would have been in the tvbuff had a
snapshot length large enough for all frames been specified (if
the snapshot length *was* large enough, that would be equal to
the amount of data in the tvbuff);
the amount of data that would have been in the tvbuff had packet
reassembly been done (if packet reassembly is done, or if the
packet is contained entirely within one lower-level packet, that
would be equal to the previous number);
(and there could potentially be other lengths to handle, for example, a
non-fragmented IP datagram with a too-large length value, or a partial
IP datagram contained within an ICMP error packet).
With a scheme such as that, the reported length would be equal to the
length, and the "reassembled length" would be set to the length reported
in the header, and your dissector would end up going past the end of the
reported length, and the exception thrown in that case would be reported
as "Unreassembled Packet" rather than "Malformed Frame".
(I have partially-completed code to do that. Hopefully I'll get time to
finish that at some point, although work, moving to a new house, setting
up DSL at the new house, etc., along with *other*
Ethereal/tcpdump/libpcap stuff, will get in the way....)
However, with the current scheme, "tcp_dissect_pdus()" would set the
reported length to the length from the header, causing the
"Unreassembled Packet" error to be reported with BoundsError and show up
as "Short Frame", rather than as "Malformed Packet" or "Unreassembled
Packet".
If the packet isn't being reassembled, "tcp_dissect_pdus()" should, for
now, probably set the reported length to a value no larger than the
remaining reported length in the tvbuff, to avoid that confusion.
I suspect that, in this case, your packets aren't getting reassembled,
for whatever reason. Is the TCP checksum valid? (Note that many
gigabit Ethernet interfaces, and possibly even some slower interfaces,
support TCP checksum offloating; outgoing packets are typically handed
to the mechanism used by libpcap by the host's networking stack, which
would *not* have set the checksum if TCP offloading is being done, so
the packets as "captured" don't have the correct checksum, even though
they might have had the correct checksum when trasmitted on the wire.)
> That particular conversation, I live-captured and then saved with ethereal
> (sorry for the confusion). Would your last suggestion still apply if this was
> the case?
If you didn't explicitly specify a snapshot length in the capture,
Ethereal would have defaulted to 65535, in which case the "-s"
suggestion wouldn't apply.
