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
>
