Ethereal-dev: [ethereal-dev] "Half-conversations" for TFTP, SMTP, and possibly other protocols
On Thu, Jul 13, 2000 at 11:46:09AM -0700, Guy Harris wrote:
> > What causes the different behavior in Ethereal is that some SNMP agents
> > reply to GET message on the well-known contact port (161), whereas
> > others reply on a different port (basically, iterative vs concurrent
> > server model).
>
> Oh, joy, another case where we have to use the same hack we use for
> TFTP.
>
> (Not that I should be griping too much, as when I originally did the
> NetBIOS-over-TCP implementation for NetApp filers, I think there were
> cases where NetBIOS Name Service packets weren't sent from port 137; it
> worked, at least in the situations we ran across then, but I would have
> caused similar problems with Ethereal.)
...but those packets were, at least, going *to* port 137, so that
wouldn't actually cause similar problems.
> I'll look into providing better support for that hack, so we can use it
> for other datagram-transport-layer request/response protocols.
One idea might be to have something I'm calling a "half-conversation";
a "half-conversation" remembers only the source address and port.
The SNMP dissector would, for an SNMP request, register the source
address and port as a "half-conversation", with the SNMP dissector
associated with it.
The UDP dissector (and possibly the dissectors for any other datagram
protocols atop which SNMP can run) would check for half-conversations
after checking for conversations, plugins, and dissectors registered
with ports, but before checking heuristic dissectors; it would call a
routine checking whether the destination address and port of a packet
matched any half-conversations. (I'm presuming here, for now, that
the clients for SNMP, and other protocols, will be sending their
requests to the standard port. I am *not* presuming that if the client
sends a request to address X, port Y, that the response will necessarily
come back from address X; I suspect that it won't necessarily do so.)
This should handle the SNMP case.
It should *also* handle part, if not all, of the TFTP case; the TFTP
dissector would, for a TFTP request sent to the standard TFTP port,
register the source address and port as a half-conversation, with the
TFTP dissector associated with it.
It could either then just leave that half-conversation in place, or,
when it sees the next request from the client, register that
address/port pair as a full conversation.
One problem here is that if a client sends an SNMP request from port X,
and then, later, reuses port X for some other protocol using
half-conversations (e.g., TFTP), the new dissector would then register
that client's address plus port X as a half-conversation for itself,
overriding the previous registration. If you then scrolled back to an
SNMP reply, and clicked on it, it would be misdissected with the new
dissector.
This might be solved by associating with those packets (using Richard
Sharpe's mechanism for attaching protocol data to a frame) a pointer to
a half-conversation structure; the SNMP dissector could attach to the
frame, as data for the dissector that called the SNMP dissector (that
other dissector would have to somehow supply, e.g. in the "packet_info"
structure, the right protocol number for SNMP to use), a pointer to the
half-conversation structure, and that other dissector would first check
for a data structure associated with it for a frame - if it's there, the
frame is handed to that half-conversation's dissector.
This would require that the SNMP (and other) dissectors know how to
attach the appropriate state; the right way to handle that might be to
have dissectors such as UDP supply, instead of a protocol number, a
pointer to a routine that makes that attachment.
