Hi Anders, Many thanks for your reply.
My protocol carries a magic word at the beginning and may go in whatever port. So, it has to be heuristic. Right? The protocols stack would be: IP -> TCP -> My protocol -> RTPS I will take into account to include the preference to turn the heuristic off. Thanks, Juanjo Martin On Thu, Nov 27, 2014 at 1:37 PM, Anders Broman <[email protected]> wrote: > Hi, > > “Next dissector” in TCP and UDP dissectors is by default determined by > first looking at the port numbers and calling …try_port to see if a > dissector is registered for that source or destination port if that fails > it continues > > With the heuristic tables and finally calls the data dissector if no match > was found. > > > > Heuristics works best for protocols with a distinct signature in the first > bytes like a magic number. In other cases it works less well. RTP is an > example of a protocol less suited for heuristics, obviously I don’t know how > > Well your protocol suits the bill. > > > > If your protocol always carries SRTP I’d implement it as a UDP/TCP > protocol registering on port(ranges) specified in preferences the default > being 0(not registered) and perhaps as a heuristic protocol too if the > heuristic has a reasonable chance of success, perhaps with a preference to > turn the heuristic off like in the RTP dissector. > > > > Then I’d look up the handle of the SRTP dissector and call that > unconditionally for the payload of your protocol. Actually pretty much the > way the RTP dissector works I think. > > > > Just my 2 cents > > Regards > > Anders > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Juan Jose Martin > Carrascosa > *Sent:* den 27 november 2014 13:05 > *To:* Developer support list for Wireshark > *Subject:* Re: [Wireshark-dev] New dissector between existing protocols > > > > Hi again, > > > > I have been reading some source code (UDP), and I have found the following: > > > > 1) When the dissection is completed, we call "decode_udp_ports". > > 2) Within this function, we get a subset of the tvb with next_tvb = > tvb_new_subset(tvb, offset, len, reported_len); > > 3) We provide that subset to the heuristic dissectors registered > with call_heur_dissector_direct(udp_p_info->heur_dtbl_entry, next_tvb, > pinfo, tree, NULL); > > > > I will assume that this is the way to go and I will implement it like this. > > > > Thanks! > > Juanjo Martin > > > > On Thu, Nov 27, 2014 at 12:09 PM, Juan Jose Martin Carrascosa < > [email protected]> wrote: > > Hi all! > > > > I have to implement a new dissector that goes between TCP and RTPS. The > name is not decided yet so let's call it XXX. I wonder, what is the best > way to proceed here: > > > > 1) Currently, RTPS is already registered with UDP and TCP. Register it > also with XXX. I don't know what steps do I need to do in the XXX dissector > to let other dissectors listen to this one... > > > > 2) Do an #include packet-rtps.h in the packet-xxx.c dissector and call the > function dissect_rtps with its parameters. > > > > 3) Other approach that I am not aware of but you consider right. > > > > Please, in case the proper way to do things is number one, can you point > me to any example or documentation? I am planning to provide this to the > Wireshark community and I want to make it correctly. > > > > If you need any extra information, please let me know it. > > > > Thanks, > > Juanjo Martin > > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
