On Fri, May 02, 2003 at 04:54:00PM -0400, nak26 wrote:
> thanks for the quick response, and directions.
> I tried it, but I still get a "short frame" exception.
>
> >>Many binary protocols running atop TCP have a header, early in the
> >>message, that specifies the size of the message.
>
> yeah..., my header has a field, specifying the size of the message (including
> the header)...in the cases when the message gets brokenup, the size reported
> in the header is bigger that the length of the tvb.
>
> >For those protocols, you can usually use the "tcp_dissect_pdus()"
> >routine, which takes, as arguments:
>
> I did call this function passing all the required arguments, but still got the
> "short frame" message. I stepped (ddd) through the code - tcp_dissect_pdus()
> calls my message_dissector
It should call your length routine before it calls your message
dissector.
> (I have a broken-up message captured with tcpdump),
If it's captured with "tcpdump" and you didn't use the "-s" flag to
specify a snapshot length >= the maximum link-layer frame size, not only
is your message broken up, but all you have are the first 68 bytes or so
of the pieces, meaning they can't ever be put back together.
> passing a tvbuff with a length N, and N < M, where M is the length
> that the header is reporting (the differense N-M is sent in subsequent TCP
> packets). And of course my message dissector goes out of bounds - BoundsError
> exception is thrown, and finally ReportedBoundsError exception is thrown,
> which I believe displays "short frame".
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*.
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.
This suggests that:
> What Am I doing wrong?
...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.
