| Commit message (Collapse) | Author | Age |
| |
|
|
|
| |
The Train Real Time Data Protocol (TRDP) is a UDP/TCP-based communication protocol designed for IP networks in trains, enabling data exchange between devices such as door controls and air conditioning systems. It is standardized by the IEC under IEC 61375-2-3 and is not related to the Remote Desktop Protocol (RDP).
|
| |
|
| |
|
|
|
|
|
|
|
| |
See also #2523
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
|
|
| |
ISO/IEC 14908-4 defines how to tunnel Control Network Protocol (CNP) over IP networks. It encapsulates protocols like EIA-709, EIA-600, and CNP, making it a versatile solution for building automation and control systems.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Use DNS information to get a better First Packet Classification.
See: #2322
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix detection of WebDAV and Gnutella (over HTTP)
Fix detection of z3950
Add two fuzzers to test `ndpi_memmem()` and `ndpi_strnstr()`
Remove some dead code:
* RTP: the same exact check is performed at the very beginning of the
function
* MQTT: use a better helper to exclude the protocol
* Colletd: `ndpi_hostname_sni_set()` never fails
Update pl7m code (fix a Use-of-uninitialized-value error)
|
|
|
| |
See: #2484
|
|
|
| |
See #2484
|
| |
|
| |
|
|
|
|
|
|
| |
Remove some code never triggered
AFP: the removed check is included in the following one
MQTT: fix flags extraction
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
| |
Since 070a0908b we are able to detect P2P calls directly from the packet
content, without any correlation among flows
|
|
|
|
| |
Avoid that useless code is copy-and-pasted into new dissector, as in
https://github.com/ntop/nDPI/pull/2470#discussion_r1639384434
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==29508==ERROR: AddressSanitizer: SEGV on unknown address 0x50710145d51d (pc 0x55cb788f25fe bp 0x7ffcfefa15f0 sp 0x7ffcfefa1240 T0)
==29508==The signal is caused by a READ memory access.
#0 0x55cb788f25fe in ndpi_search_zoom /home/ivan/svnrepos/nDPI/src/lib/protocols/zoom.c:210:24
#1 0x55cb787e9418 in check_ndpi_detection_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7174:6
#2 0x55cb7883f753 in check_ndpi_udp_flow_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7209:10
#3 0x55cb7883bc9d in ndpi_check_flow_func /home/ivan/svnrepos/nDPI/src/lib/ndpi_main.c:7240:12
```
Found by oss-fuzzer
See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=69520
|
|
|
|
|
|
|
|
|
|
| |
After a flow has been classified as RTP or RTCP, nDPI might analyse more
packets to look for STUN/DTLS packets, i.e. to try to tell if this flow
is a "pure" RTP/RTCP flow or if the RTP/RTCP packets are multiplexed with
STUN/DTLS.
Useful for proper (sub)classification when the beginning of the flows
are not captured or if there are lost packets in the the captured traffic.
Disabled by default
|
| |
|
| |
|
|
|
|
|
| |
TODO: TCP reassembler on top of UDP reassembler
See: #2414
|
|
|
|
|
|
| |
RFC4571 is not the only way to wrap RTP messages in TCP streams.
For example, when RTP is encapsulated over TURN flows (i.e. via DATA
attribute) there is no additional framing.
See also 6127e0490
|
|
|
|
|
| |
Support rtp/rtcp over tcp as per rfc4571.
Signed-off-by: mmaatuq <mahmoudmatook.mm@gmail.com>
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
| |
The original code handled also TCP/TLS, but it was removed in 6fc29b3ae
|
|
|
|
|
|
|
|
|
| |
* detect more Kafka request packet's
* requires less flow memory
* same detection behavior as before e.g. no asym detection implemented
(can be done by dissecting responses, requires more effort)
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRC has its best times well behind, but there are still some servers
using it.
We should try to simplify the detection logic, still based on OpenDPI
logic.
Let's start with some easy changes:
* try to detect TLS connection via standard hostname/SNI matching,
removing an old heuristic (we have never had any trace matching it);
* add some basic server names;
* once we detect that the flow is IRC, we don't have to perform
anything else;
* remove HTTP stuff; real HTTP flows never trigger that data path
* use `ndpi_memmem()` when possible
|
| |
|
|
|
|
| |
Add an explicit upper limit on the number of packets processed before
giving up.
|
|
|
|
|
|
|
|
|
| |
There is some overlap between RTP and Raknet detection: give precedence
to RTP logic.
Consequences:
* Raknet might require a little bit more packets for some flows (not a
big issue)
* some very small (1-2 pkts) Raknet flows are not classified (not sure
what do do about that..)
|
| |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
| |
See RFC8122: it is quite likely that STUN/DTLS/SRTP flows use
self-signed certificates
Follow-up of b287d6ec8
|