Add auxiliary stuff for the COTP protocol about ndpi

[0xA50C1A1]

@utoni, @0xA50C1A1

In think that we have a few options:

1. change nothing and keep doing as before

2. keep creating a new dissector for each protocol but use a generic helper `is_cotp()` to avoid code duplication

3. create a new cotp dissector, and add all the sub-classification logic there

4. sub-protocols logic (not sure if it works, since the sub-protocols callbacks are called only once, i.e. only for one packet)

I don't have strong opinions and I am fine with all these options. If I did the work, I would probably do 3) and switch to 4) in the future if necessary, but, as I said, I am fine in any case

Hmm, option 2 seems the most optimal to me.

[0xA50C1A1]

One question: Do we want to keep the subprotocol feature as it is or remove it?

Yeah, that's definitely worth keeping. There are many protocols working on top of HTTP (IPP for example), so I think the subprotocols feature is great for such cases.

[IvanNardi]

One question: Do we want to keep the subprotocol feature as it is or remove it?

Yeah, that's definitely worth keeping. There are many protocols working on top of HTTP (IPP for example), so I think the subprotocols feature is great for such cases.

+1

[0xA50C1A1]

@IvanNardi @utoni What do you think about it?

[utoni]

If I understood that correctly, you want to call a certain dissector after another protocol dissector at a lower layer successfully classified the flow, right?

That was the initial idea of the "subprotocol" thingy, that I've added a few months (or years? O.o) ago.

[0xA50C1A1]

If I understood that correctly, you want to call a certain dissector after another protocol dissector at a lower layer successfully classified the flow, right?

Yea.

[0xA50C1A1]

I dunno if it would be correct to call encapsulated stuff a sub-protocols (for me it's kind of like HTTP Live Streaming) in that case, since COTP is a transport protocol, even though in today's world it runs on top of the another transport protocol - TCP. 😄

[IvanNardi]

Just to understand the scope of this issue...
If I checked the code correctly, right now we have COTP stuff only for 3 protocols in 2 different dissectors:

• COTP/S7COMM
• COTP/S7COMM_PLUS
• COTP/RDP

In all these cases the identification of the COTP "sub-protocol" is very trivial, basically checking only a few bytes

How many others cases do you think we will have?

[0xA50C1A1]

How many others cases do you think we will have?

Atm I'm working on IEC 61850 MMS protocol dissector, which like some other ICS protocols runs on top of the ISO stack. There's also an IEC 60870-6 TASE.2, but this is more of a special case of MMS.

Well, I'm sure there'll be something else.

[IvanNardi]

@utoni, @0xA50C1A1

In think that we have a few options:

1. change nothing and keep doing as before
2. keep creating a new dissector for each protocol but use a generic helper is_cotp() to avoid code duplication
3. create a new cotp dissector, and add all the sub-classification logic there
4. sub-protocols logic (not sure if it works, since the sub-protocols callbacks are called only once, i.e. only for one packet)

I don't have strong opinions and I am fine with all these options.
If I did the work, I would probably do 3) and switch to 4) in the future if necessary, but, as I said, I am fine in any case

[utoni]

I am also fine with option 2.
One question: Do we want to keep the subprotocol feature as it is or remove it?