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).
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.
This cache was added in b6b4967aa, when there was no real Zoom support.
With 63f349319, a proper identification of multimedia stream has been
added, making this cache quite useless: any improvements on Zoom
classification should be properly done in Zoom dissector.
Tested for some months with a few 10Gbits links of residential traffic: the
cache pretty much never returned a valid hit.
Avoid code duplication between these two protocols.
We remove support for RTCP over TCP; it is quite rare to find this kind
of traffic and, more important, we have never had support for RTP
over TCP: we should try to add both detecion as follow-up.
Fix a message log in the LINE code
The new values has been checked against the ones reported by Wireshark.
Found while fixing a Use-of-uninitialized-value error reported by
oss-fuzz
```
==7582==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x5a6549abc368 in ndpi_compute_ja4 ndpi/src/lib/protocols/tls.c:1762:10
#1 0x5a6549ab88a0 in processClientServerHello ndpi/src/lib/protocols/tls.c:2863:10
#2 0x5a6549ac1452 in processTLSBlock ndpi/src/lib/protocols/tls.c:909:5
#3 0x5a6549abf588 in ndpi_search_tls_tcp ndpi/src/lib/protocols/tls.c:1098:2
#4 0x5a65499c53ec in check_ndpi_detection_func ndpi/src/lib/ndpi_main.c:7215:6
```
See: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=68449&q=ndpi&can=1&sort=-id
eDonkey is definitely not as used as >10 years ago, but it seems it is
still active.
While having a basic TCP support seems easy, identification over UDP doesn't
work and it is hard to do it rightly (packets might be only 2 bytes long):
remove it.
Credits to V.G <v.gavrilov@securitycode.ru>
P2P video player PPStream was discontinued shortly after the purchase of PPS.tv by Baidu (iQIYI) on 2013 (see https://www.techinasia.com/report-baidu-acquires-video-rival-pps)
So we remove the old `NDPI_PROTOCOL_PPSTREAM` logic and add `NDPI_PROTOCOL_IQIYI` id to handle all the iQIYI traffic, which is basically video streaming traffic.
A video hosting service, called PPS.tv, is still offered by the same company: for the time being we classified both services with the same protocol id.
Microsoft UDP traffic over port ~3478 is voip traffic, using some kind
of proprietary STUN-like protocol: so use the most specific protocol id.
More important, we definitely want `Stun/Skype_TeamsCall` and not
`Stun/Skype_Teams`
* Add The Elder Scrolls Online support
* Use ndpi_memmem instead of memmem from libc
* Add protocol description
* Change selection bitmask to V4_V6
* Update protocols.rst
Enable parsing of Mapped-Address attribute for all STUN flows: that
means that STUN classification might require more packets.
Add a configuration knob to enable/disable this feature.
Note that we can have (any) STUN metadata also for flows *not*
classified as STUN (because of DTLS).
Add support for ipv6.
Restore the correct extra dissection logic for Telegram flows.
Follow up of 31c706c3db and
75485e177c.
Allow fast classification by ip, but give time to other dissectors to
kick in (for example, the TLS code for the Telegram Web flows).
Even if we don't classify it anymore at the very first packet (i.e. SYN)
we fully classify Telegram traffic at the first packet with payload, as
*any* other protocol.
This way, we always have the proper category, the proper confidence
for the UDP flows and we don't overwrite previous classifications (TLS
or ICMP)
Remove old and stale identification logic for TCP flows
