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
