thanks again...but I still have more questions...
>
>It should call your length routine before it calls your message
>dissector.
>
yes it does that...my length routine returns the number of bytes that are
supposed to be in the message (as reported by my message header). The value
gets assigned to the reported_length variable (in the partiular case 2076
bytes), and is larger than the length of the tvb (which is 1388 bytes long).
>
>BoundsError displays "Short Frame" - and it means that something tried
>to fetch data past the end of the tvbuff *but before the end of the
>packet, as reported by libpcap*.
>
My message_dissector tries to fetch data and goes past the end of the tvb, and
it does so because the length reported in the header is bigger than the length
of the tvb. Before my message dissector gets called, tcp_dissect_pdus()
massages the tvb (before passing it as an argument to my message_dissector).
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.
What also puzzles me from what you say above is *but before the end of the
packet. Right after the "Short Frame" - packet, I see two more TCP packets,
carrying the remaining payload (worth 2076 - 1388 bytes). What I think happens
is that the tcp buffer gets full (since some of our messages are quite large)
and the packet goes out-the-door. Hence the remaining data gets shipped in
subsequent packet(s) (without a header, just straight from the cutoff point).
>If you capture with a snapshot length that's less than the length of a
>given packet, libpcap will supply only the snapshot length's worth of
>data (probably because the OS only supplies that much data, and doesn't
>bother spending CPU cycles copying the rest), but will report to its
>caller (Ethereal/Tethereal, in this case) both the length of the data
>that was captured (which is the snapshot length, in that case) and the
>actual length of the frame. The latter becomes the "reported length" of
>the tvbuff.
>..the answer to your question might be "capturing with tcpdump without
>specifying a snapshot length greater than the tcpdump default of 68".
>Ethereal won't reassemble packets if there's stuff missing from the
>middle due to a too-short snapshot length.
>
>If you were doing that, try capturing with "-s 65535", and try again.
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?
Thanks,
Nik
