|From: Jerry Talkington
|
|
|On Thu, Apr 29, 2004 at 10:36:03PM +0200, Olivier Biot wrote:
|> From: Jerry Talkington
|>
|> | The more I think about this/look at the code, the less I like this
|> idea.
|> | There doesn't really seem to be a way to add media types to the
|> protocol
|> | hierachy without creating a dissector for each one encountered.
|>
|> Consider the fact that there is already a WBXML dissector, a GIF
|> dissector and a JPEG/JFIF dissector. Then there is also the
|> "line-based text" dissector. And there are more.
|>
|> The way it is now makes much sense to me.
|
|Sure, but 99% of the traces that I look at have at least one
|object type
|that doesn't have a dissector. I was just pontificating that it would
|be useful to have the number of objects of X media type in the
|hierarchy except...
OK I got your point and it makes sense to me!
Fortunately this can easily be dealt with, by defining a generic "media"
dissector (which would be used instead of the generic "data" dissector) in
case there was no match for a given media type.
All dissectors that currently use the "media_type" string dissector table
defined in packet-http.c will have to be updated then in order to call the
"media" dissector instead of the "data" dissector in case of no match.
And that leads to another function I think may be interesting to use
(epan/packet.h):
/* Look for a given perl-compatible regular expression
in a given string dissector table and, if found, call
the dissector with the arguments supplied, and return
TRUE, otherwise return FALSE. */
extern gboolean dissector_try_string_pcre(dissector_table_t sub_dissectors,
const gchar *string_pcre, tvbuff_t *tvb, packet_info *pinfo, proto_tree
*tree);
/* Look for a given perl-compatible regular expression
in a given string dissector table and, if found,
return the dissector handle for that value. */
extern dissector_handle_t dissector_get_string_pcre_handle(
dissector_table_t sub_dissectors, const gchar *string_pcre);
This way, one could check for "(?i)[+]xml$" (for the line-based text
dissector and "(?i)[+]wbxml$" for the WBXML dissector. I can add this
(generic media dissector, pattern match in string dissector table) over the
weekend.
|> | I have a couple ideas for a generic dissector (i.e. you pass the
|> name
|> | and desciption, and a data dissector is created on the
|fly,) but I'm
|> not
|> | sure how worthwhile it would be, I'll have to do some more
|> | investigation.
|>
|> This is not really required, I think. There are much more important
|> flaws in the protocol hierarchy code today as there is no means today
|> of distinguishing between protoX on top of protoX or just an
|> encapsulation of multiple protoX messages. This is easy to see with
|> many X11 captures where concatenation of X11 messages in one packet
|> are very common. The protocol hierarchy will show this as being X11
|> over X11 over ... over X11.
|>
|> Believe me, there is no simple means of deciding whether once it is
|> encapsulation and the other time it is fragmentation or tunnelling.
|
|this. I was also thinking that I might just work on getting some
|more/better HTTP statistics going. But, there are other things that I
|want to work on first (mainly decompression of HTTP entity-bodies.)
Go ahead!
Regards,
Olivier