At 01:27 PM 9/28/00 -0700, Darren New wrote:
>Richard Sharpe wrote:
>> Now, by more robust, I assume you mean that CR by itself or LF by it self
>> should be OK?
>
>Yes, basically. I just expect that to be a common problem.
>
>> I think that I should flag syntax/protocol errors however, as well ...
>
>Yes. I'm also not sure if you can flag problems like headers being
>inconsistant with previous headers, but things you can discover from a
>single packet would certainly be useful.
This can be hard, especially when you consider TCP segment reordering may
have taken place ... I do keep some state info on the first scan of the
packets, and can increase that state info to check more things.
>I would also expect it to be handy if one could (say) sort by channel, or by
>message, so one could inspect all the frames of a single REQ and its RSP, or
>all the frames only on channel 7, say. I didn't see any way of doing that,
>but I don't know much about ethereal to start with. Sort of like following
>a TCP conversation packet by packet.
OK, this is easy, and I intend to do this stuff. I already gather the
channel number and other header integers as integers in the dissector, so
it is now only a question of a small matter of programming :-)
I will have to add hidden fields for each message which have names like:
bxxp.rsp.channel and its value
bxxp.channel and its value
By including both allows you to search for responses on a particular
channel as well as any message on a particular channel.
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba