Ethereal-dev: Re: [ethereal-dev] Follow-the-Stream (was static vs. dynamic columns)
> I was under the impression that someone was adding hooks so that if an
> application-level protocol message was incomplete, the incomplete part
> of the message would be held based on a hash of the sender/receiver IP
> addresses and ports until the rest of the message was seen. I think
> someone had started this code (maybe for SMB?), and there was some
> discussion about holding off on decoding too many application-level
> protocols until the general capability was completed, so that every
> application-level protocol-decoding routine didn't have to write (or
> copy) this code.
I'm not sure I'd heard about anybody actually doing that.
I've wanted to come up with some scheme to handle "packets" above the
transport layer that consist of multiple frames - or, for that matter,
that are packed more than one to a frame - but I hadn't heard that
anybody was working on that right now.
One thing we probably should do, at some point, is have "dissect_tcp()"
somehow reassemble TCP connections, so that "Follow TCP Stream" doesn't
have to do it; reassembling TCP connections would also be necessary for
handling multiple-frame "packets" (ONC-RPC-over-TCP, SMB, DNS, and even
various byte-stream protocols like HTTP, so that we could handle, say,
persistent HTTP connections), and it might also let us label TCP
retransmissions as such.
It might also be nice to
1) reassemble IP fragments (ONC-RPC-over-UDP);
2) "reassemble" UDP "conversations", so that for UDP protocols
as well as TCP protocols you can select a packet and say
"show me everything in this conversation" (note that an NFS
"conversation", whether over UDP or TCP could involve more than
one server port - it might include the mount and lock manager
protocols as well as NFS).
