Wireshark-dev: Re: [Wireshark-dev] Http dissector - Am I missing something?
From: LEGO <luis.ontanon@xxxxxxxxx>
Date: Thu, 7 Sep 2006 18:06:35 +0200
XML's dissector is called as an heuristic dissector for http, can't you do like it does? Luis On 9/7/06, Bryant Eastham <beastham@xxxxxxxxxxx> wrote:
All- I have done several plugin dissectors in the past for internal protocols, all TCP- and UDP-based. I am now trying to add a plugin for a protocol that uses HTTP as the transport. Easy, I thought! Well, not so easy it appears. I am confused by the logic in packet-http.c around line 1059: if (handle == NULL && headers.content_type != NULL) { /* * We didn't find any subdissector that * registered for the port, and we have a * Content-Type value. Is there any subdissector * for that content type? */ save_private_data = pinfo->private_data; if (headers.content_type_parameters) pinfo->private_data = ep_strdup(headers.content_type_parameters); else pinfo->private_data = NULL; /* * Calling the string handle for the media type * dissector table will set pinfo->match_string * to headers.content_type for us. */ pinfo->match_string = headers.content_type; handle = dissector_get_string_handle( media_type_subdissector_table, headers.content_type); /* * Calling the default media handle otherwise */ if (handle == NULL) { handle = media_handle; } } This seems to imply that if I have a content-type, then I cannot have a heuristic subdissector. The reason is the last line, that forces the handle to "media_handle". Here is my issue: our protocol uses content-type as "application/octet-stream", the contents being binary. We identify our packets (besides the URL) with a type modifier on the content-type that is specific to our protocol. Unfortunately, the logic as I understand it for handling content-type is too specific to handle this situation (no one dissector should handle all "application/octet-stream" packets, right?). This seems like a case for a heuristic subdissector, but that is disabled by the forcing of handle to media_handle. I seem to remember that changes were made to resolve this issue a while ago, but maybe I was dreaming... What am I missing? Bryant Eastham Chief Architect Panasonic Electric Works Laboratory of America, Inc. Salt Lake City Lab 4525 South Wasatch Blvd., Suite 100, Salt Lake City, Utah 84124 Phone : 801.993.7124 Email: beastham@xxxxxxxxxxx Fax: 801.993.7260 Web: http://slc.mew.com <http://slc.mew.com/> _______________________________________________ Wireshark-dev mailing list Wireshark-dev@xxxxxxxxxxxxx http://www.wireshark.org/mailman/listinfo/wireshark-dev
-- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan
- References:
- [Wireshark-dev] Http dissector - Am I missing something?
- From: Bryant Eastham
- [Wireshark-dev] Http dissector - Am I missing something?
- Prev by Date: Re: [Wireshark-dev] tcp_dissect_pdus
- Next by Date: Re: [Wireshark-dev] [Patch] epan/make-sminmpec.pl
- Previous by thread: [Wireshark-dev] Http dissector - Am I missing something?
- Next by thread: [Wireshark-dev] win32: nmake setup: can't find cl
- Index(es):