[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

See packet-tftp.c and packet-snmp.c

See the handling of conversation and registering/unregistering
protocol handlers.

This was successfully used for an implementation that started by using
TFTP and then switched over to do SNMP on the very same socketpair.


Though I think you should probably collapse the two
dissectors/protocols into a single dissector/protocol and just use
heuristics inside to determine what it is.



On 7/5/05, Martin Mathieson <martin.mathieson@xxxxxxxxxxxx> wrote:
> Hi,
> 
> I need a bit of advice about the design of the Microsoft Media Streaming
> dissectors (packet-mms-control.c and packet-mms-data.c).
> 
> The current implementation handles these as 2 distinct protocols, where:
> - control is always over TCP with a well-known (registered) server port
> - there is a command from the client which indicates the client
> address/port
> for the data stream, so the conversation is set up (currently only when UDP
> is indicated)
> - the data stream dissector is called OK
> - The client can also send some (one) command to the server over UDP.  This
> is currently implemented as part of the data dissector.
> 
> Now I'm trying to add support for TCP data streams.  In a capture I'm
> testing with, the client reuses the existing control TCP connection for
> data.  This means that over the same TCP connection 2 different protocols
> are now being used.  These are distinct protocols in that they have no
> common header (the control protocol has a distinctive signature).
> 
> I've been looking for an elegant way to make the right dissector be called
> for the right packet.  I started off using tcp_dissect_pdus(), but this
> seems quite limited because you need to supply an old-style dissector that
> can't reject a packet.
> 
> I changed to using a new-style dissector for control, hoping that after it
> rejects what looks like a data packet the data dissector would then be
> invoked because of the conversation that was set up with the client's TCP
> address/port, but this doesn't happen...
> 
> 
> I can think of 2 unattractive options at the moment:
> (1)  make the control protocol purely a heuristic dissector (which could
> check for the previously-registered server port).  As long as I set the TCP
> preference to try heuristic sub-dissectors first, this should hopefully let
> the control dissector reject data packets and the data dissector claim the
> data packets because of the conversation that has been created.  I would
> prefer this if it weren't for the preference setting issue.
> (2)  combine the control and data dissectors into one single dissector that
> registers the server tcp port, the data command udp port and also has
> conversations setup for data streams.  The single dissector function will
> then examine the port/signature in each frame and work out how it should be
> dissected.  This seems to be close to what is done in the xine
> implementation of mms, and would allow one simple filter to match with
> control and data packets.
> 
> Am I missing a trick?
> Best regards,
> Martin
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>