From: LISA M REDEKOP [mailto:lrede024@xxxxxxxxxx]
Sent: Friday, January 26, 2001 9:12 AM
> Q1. I have a sample of packets where there is RTSP
> on top of TCP, but port 7070 is being used instead
> of port 554 (the standard RTSP port).
> Ethereal does not dissect the RTSP layer, could you
> suggest a way to do this? (point me in the right
> direction <but read Q2 before answering>)
>
See Gilbert's answer. But I suspect that this is only
a patch and doesn't fix the long term problem, see
the heuristic information below.
> Q2. I thought of "grepping" for RTSP or other words
> unique to RTSP and starting a conversation, however
> these packets that I'm interested in have a layer on
> top of RTSP for which I've already started a convesation.
To do this you need to check the heuristic dissector code.
These dissectors will examine the packet data and dissect
it if possible. If the dissector processes the data it will
return a true value to indicate so, otherwise it returns
a false and other dissectors are used.
This isn't documented in the README.developer. Examine
packet.c for the implementation of heuristic lookups and
packet-rtcp.c for an example of how to write a heuristic
dissector.
> Is it possible to have two dissectors for one
> conversation (maybe using conversation.old_d,
> conversation.new_d)?
Maybe. It depends upon what you are using for the 'port'
value. The word port is not a very good one because you
can use any 32 bit integer here. If your conversation are
based upon TCP ports, as I suspect, you have a problem.
You can create the conversation in the RTSP and add a
pointer to the sub-dissector in the conversation struct using
the data value in the conversation_new call. Then your RSTP
dissector would extract this pointer to call the sub-dissector.
The problem with this is that if the sub-dissector has a
data pointer we just broke it (see next paragraph).
You can use the conversation->index value to create a local
storage pointer for the data structures that you need. This
will solve the sub-dissector data storage problem in the last
paragraph. See the README.developer section 2.2.5.
> And what are the fields old_d and new_d used for?
conversation.old_d and conversation.new_d are for the
different styles of dissectors, the old_d is for the old
type that use the u_char* for the packet data pointer and
the new_d is for the tvbuffer style.
Of course you are using the tvbuffer style, right ;-)
Jeff Foster
jfoste@xxxxxxxxxxxx
