This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Multiple UDP Payload Protocols

0

I have a UDP payload dissector (1) I've developed that works just fine. Occasionally, there will be data that is not part of dissector 1 and is a different protocol that was attached to the same UDP payload.

I've written another dissector for type 2.

Is there a way for the 2nd dissector to automatically dissect the remaining bytes? Dissector 1 returns the number of bytes it actually used and I was hoping wireshark would try other protocols on the remaining bytes.

I could specifically call dissector 2 from 1, but I don't really want to do that. There could be many other protocols and they could be in different orders.

dissector_next doesn't really exist, but that's the functionality I'm looking for. I dissect the first protocol and hand off the remaining bytes to whatever protocol that may apply.

EDIT: Words.

asked 16 Apr '13, 12:40

dlovelace's gravatar image

dlovelace
11113
accept rate: 0%

edited 16 Apr '13, 12:43


One Answer:

1

If I understand you correctly, you have a protocol that is identified by wireshark by it's UDP port number (or through heuristics) and the first part of the UDP payload is always your protocol (protocol 1 in your question). After the dissector for protocol 1 has finished dissecting it's bytes, there is still bytes left in the UDP payload and nothing in the protocol 1 headers tell you which protocol the remaining bytes belong to. So:

There could be many other protocols and they could be in different orders.

And how would you recognize which bytes belong to which protocol? Is there a header with certain values for certain protocols? Or are there some heuristics that can determine which protocol is used for (part of) the remaining bytes?

If there is no value in either protocol 1 or the first part of the remaining bytes pointing to a distinct protocol, then you could build a heuristic protocol table and let all the possible protocol dissectors for the remaining bytes register to that table. Each dissector determines whether the next bytes are indeed valid bytes for the protocol. If not, it returns 0, if so, it returns the number of bytes it recognized and dissected. The protocol 1 dissector will have to loop through the remaining bytes this way until all remaining bytes have been dissecter.

answered 16 Apr '13, 15:31

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Protocol 1 is heuristic as is Protocol 2. Both of these protocols are ASTERIX-like and use a header byte/length. Protocol 1 decodes all the UDP payload bytes that are its type and finishes. There may or may not be leftover bytes. Occasionally there are 2 instances of Protocol 1 and then leftover bytes that are Protocol 2. It would be far easier if the spec said just 1 Protocol per packet, but alas, no.

If there are leftover bytes, I was curious if Protocol 1 can 'hand over' the extra bytes to Wireshark to see if any other protocol applies. The heuristic code in Protocol 2 would sense that it fits and decode the remaining bytes. I don't really want to write code in Protocol 1 to determine what the remaining bytes are and call those sub dissector manually. They are separate Protocols and I don't really want to combine them in any way. If there's an automatic way of doing it, that would be swell.

That probably explains it a bit better.

(16 Apr '13, 16:09) dlovelace

Both of these protocols are ASTERIX-like

Maybe the code of the asterix plugin can help you. See the links in my answer to the following question:

http://ask.wireshark.org/questions/20109/problem-with-tcpip-decoding

(16 Apr '13, 16:14) Kurt Knochner ♦

I'll look at it further, but it is in french. Haha.

The one thing the Asterix dissector does itself is that it will handle all the Asterix protocols. Mine are technically different dissectors so I can't handle Protocol 2 in the Protocol 1 code.

(17 Apr '13, 04:58) dlovelace