Comments (11)
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.
from ndpi.
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.
from ndpi.
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
from ndpi.
@IvanNardi @utoni What do you think about it?
from ndpi.
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.
from ndpi.
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.
from ndpi.
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. 😄
from ndpi.
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?
from ndpi.
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.
from ndpi.
In think that we have a few options:
- change nothing and keep doing as before
- keep creating a new dissector for each protocol but use a generic helper
is_cotp()
to avoid code duplication - create a new cotp dissector, and add all the sub-classification logic there
- 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
from ndpi.
I am also fine with option 2.
One question: Do we want to keep the subprotocol
feature as it is or remove it?
from ndpi.
Related Issues (20)
- Question about source of test files HOT 4
- Implement ndpi_fill_ip_domain_category HOT 1
- mqtt was identified as TLS HOT 6
- WSP Protocol support request HOT 4
- Compilation errors on MacOS-14 on ARM64 with external libraries
- DEBUG_TRACE Build fails due to domainSearchUnitTest()
- Add support for DTLS over TCP
- Typo in ndpi_utils.c "Attemot" HOT 4
- Add support for RTP/RTCP over TCP HOT 2
- Improve RTP detection HOT 4
- Wireshark reports an error after linking the nDPI HOT 10
- Stun dissector, with method type.
- A compile error occurred while cross-compiling to the mips architecture HOT 2
- ndpi_serialize_uint32_float function is doubly declared since 4.6 in ndpi_api.h HOT 2
- Support for VPN and TOR browser detection HOT 14
- np. iil HOT 1
- Research project HOT 1
- How to Integrate nDPI for Deep Packet Inspection into a Python Project? HOT 4
- New nDPI roadmap HOT 2
- Implement SSDP Metadata export
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ndpi.