On Sun, 25 Nov 2001, Guy Harris wrote:
> On Sun, Nov 25, 2001 at 04:52:30PM -0500, Brian Bruns wrote:
> > In TDS a particular PDU may start in one netlib wrapper and finish in
> > another. In order to keep sane the dissector needs to track where it is
> > from one packet to the next. As I understand it this is part of what the
> > conversation stuff does for me correct?
>
> Incorrect.
>
> The conversation code will *not* do that for you; you will have to do
> that yourself.
Ok, no problem, I did it for a TDS connection pooling program that comes
with FreeTDS, I can import a lot of that code. Just wanted to make sure I
wasn't reinventing the wheel here.
> Note also that there is no guarantee that your dissector will be called
> only once per frame, and that all calls to your dissector will be in
> sequential order; in Ethereal, the user can click on packets as randomly
> as they wish.
>
> The *first* pass through the capture is in sequential order; however,
> subsequent to that, the user could click on the last captured packet of
> a TCP connection, and then click on the first one, and then click on one
> in the middle, and then click on the one just before that, and then
> click on the one 7 packets after that, and then....
Ok, so the obvious question is, on the first time through what is the best
way to store per packet data such that it can be retrieved when packets
are subsequently accessed out of order.
> > Also does it handle retransmits/out of order packets
>
> No.
>
> The TCP dissector *should* handle that; unfortunately, currently, it
> doesn't.
Ack, this would have been most helpful.
> You could either wait for it to do so - which could mean you'd wait a
> while before having a TDS dissector - or you could just punt on that, as
> all the other dissectors running atop TCP do.
punting sounds good ;-)