At 10:25 PM 4/2/99 -0600, Gilbert Ramirez <gramirez@xxxxxxxxxx> wrote:
[Deletia]
>> I am starting to wonder if we have any standards around information
>> presented by the various decode routines. I am looking for some guidelines,
>> and don't mind being part of the solution (ie, coming up with guidelines if
>> they are needed). Are there any guidelines? As I am looking more and more
>> at TCP level protocols (like SMTP, DNS Zone Transfers, SSH, Telnet, etc),
>> it may be that there is a need for such guidelines.
>
>There are no guidelines. Ethereal has been evolving. We have mostly
>stayed away from the protocols that are stacked above the
>session-oriented transports (TCP, SPX) because of the difficulty of
>matching packets of fragmented TCP write()s. Guy has some good ideas on
>how to fix this.
Ahhh, here is the value of these discussions. This is reminding me of
things I know. Windows clients, for example, grab 4kB blocks from files.
These are sent out as one SMB response to a read request of length slightly
over 4kB. They are sent as three segments of 1460 bytes (in the first two)
making up 1500 bytes in an ethernet environment. Over PPP the segments
would be smaller (256 bytes).
Now, as I recall, Netmon simply punts, and displays the first as an SMB,
and the rest as TCP data. It is probably looking for the \255SMB on the front.
To treat these as continuation segments of the original SMB
request/response, we need some state info (another reason :-). The state I
would keep is:
<SIP, DIP, SP, DP, Session Message Len, Start Sequence #>
for each direction. Since there is no session ID in NetBIOS over TCP
(RFC1001) and I suspect for NBIPX (where we would need to keep other state
info that I do not understand at the moment, and maybe NBIPX uses a value
of MAX_XMIT that is tuned to the [P]MTU minus overhead).
>What I'd like to do in regards to this is to have an "unfragment" mode
>in ethereal. When used, multiple packets that are known to be part of a
>single TCP transmision (write()) will be coalesced together. The packet
>summary line will be two lines high. The first line will be the decoding
>of the packet (once you put all the packets together for a single TCP
>write(), you can send that entire buffer to the next higher layer,
>dissect_http() or whatever). The second line will contain a drop-down
>list of the individiual frames that make up this TCP write(). If you
>select one of these frames, a window pops up showing you the protocol
>tree and hex dump of that single frame.
Hmmm, that sounds interesting, but you lose the time relationships between
events. It will also require more GUI support/complexity.
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, NIC-Handle:RJS96
NS Computer Software and Services P/L,
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
Samba (Team member), Linux, Apache, Digital UNIX, AIX, C, ...
