aboutsummaryrefslogtreecommitdiff
path: root/tests/cfgs/caches_global
Commit message (Collapse)AuthorAge
...
* Remove "zoom" cache (#2420)Ivan Nardi2024-05-06
| | | | | | | | | 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.
* Merge RTP and RTCP logic (#2416)Ivan Nardi2024-05-06
| | | | | | | | | 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
* TLS: fix Ja4 fingerprint computation (#2419)Ivan Nardi2024-05-05
| | | | | | | | | | | | | | | | | 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: improve/update classification (#2410)Ivan Nardi2024-05-04
| | | | | | | | | | 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>
* Remove PPStream protocol and add iQIYI (#2403)0x41CEA552024-04-23
| | | | | | 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.
* Add BFCP protocol support (#2401)0x41CEA552024-04-23
|
* Remove obsolete protocols: tuenty, tvuplayer and kontiki (#2398)0x41CEA552024-04-19
|
* Add KNXnet/IP protocol support (#2397)0x41CEA552024-04-19
| | | | | * Add KNXnet/IP protocol support * Improve KNXnet/IP over TCP detection
* STUN: fix boundary checks on attribute list parsing (#2387)Ivan Nardi2024-04-12
| | | | | Restore all unit tests. Add some configuration knobs. Fix the endianess.
* Implemented STUN peer_address, relayed_address, response_origin, ↵Luca Deri2024-04-12
| | | | | | | other_address parsing Added code to ignore invalid STUN realm Extended JSON output with STUN information
* Add Label Distribution Protocol support (#2385)Vladimir Gavrilov2024-04-12
| | | | | | | * Add Label Distribution Protocol support * Fix typo * Update unit test results
* Fix `ndpi_reconcile_msteams_udp` (#2377)Ivan Nardi2024-04-12
| | | | | | | 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`
* Updated unit test resultsToni Uhlig2024-04-12
| | | | | | * fixed invalid read Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Add The Elder Scrolls Online support (#2376)Vladimir Gavrilov2024-04-10
| | | | | | | | | | | * 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
* STUN: improve extraction of Mapped-Address metadata (#2370)Ivan Nardi2024-04-08
| | | | | | | | | | | | | 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.
* Calculate packet entropy for unknown protocols. (#2369)Toni2024-04-06
| | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
* Add LoL: Wild Rift detection (#2356)Vladimir Gavrilov2024-03-26
|
* STUN: remove workaround to identify RTP trafficNardi Ivan2024-03-20
| | | | | We are able to demultiplex RTP packets in STUN flows since 3608ab01b, at least; no need to explicity call the RTP dissector
* Add FLUTE protocol dissector (#2351)Vladimir Gavrilov2024-03-19
| | | | | * Add FLUTE protocol dissector * Add flute.c to MSVC project
* Add PFCP protocol dissector (#2342)Vladimir Gavrilov2024-03-13
|
* Add Path of Exile protocol dissector (#2337)Vladimir Gavrilov2024-03-06
| | | | | * Add Path of Exile protocol dissector * Update protocols.rst
* Add Naraka Bladepoint detection support (#2334)Vladimir Gavrilov2024-03-04
|
* Add BFD protocol dissector (#2332)Vladimir Gavrilov2024-02-29
|
* Telegram: improve identificationNardi Ivan2024-02-26
| | | | | | | | | | | | | | | | | Follow up of 31c706c3dbbf0afc4c8e0a6d0bb6f20796296549 and 75485e177ccc4fafcc62dd46c6917d5b735cf7d2. 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
* Updated telegam outLuca Deri2024-02-23
|
* Improved telegram detectionLuca Deri2024-02-22
|
* Add DLEP protocol dissector (#2326)Vladimir Gavrilov2024-02-20
|
* Add ANSI C12.22 protocol dissector (#2317)Vladimir Gavrilov2024-02-15
| | | | | * Add ANSI C12.22 protocol dissector * Add UDP sample
* Skype: remove old detection logic (#1954)Ivan Nardi2024-02-12
| | | | | | | Skype has been using standard protocols (STUN/ICE or TLS) for a long, long time, now. Long gone are the days of Skype as a distribuited protocol. See: #2166
* Add detection of Gaijin Entertainment games (#2311)Vladimir Gavrilov2024-02-09
| | | | | | | | | * Add detection of Gaijin Entertainment games * Short NDPI_PROTOCOL_GAIJINENTERTAINMENT to NDPI_PROTOCOL_GAIJIN * Add default UDP port for Gaijin Entertainment games * Remove NDPI_PROTOCOL_CROSSOUT protocol id
* Add TencentGames protocol dissector (#2306)Vladimir Gavrilov2024-02-08
|
* Add Gearman protocol dissector (#2297)Vladimir Gavrilov2024-02-01
|
* Sync unit tests resultsNardi Ivan2024-02-01
|
* Allow multiple `struct ndpi_detection_module_struct` to share some state (#2271)Ivan Nardi2024-02-01
Add the concept of "global context". Right now every instance of `struct ndpi_detection_module_struct` (we will call it "local context" in this description) is completely independent from each other. This provide optimal performances in multithreaded environment, where we pin each local context to a thread, and each thread to a specific CPU core: we don't have any data shared across the cores. Each local context has, internally, also some information correlating **different** flows; something like: ``` if flow1 (PeerA <-> Peer B) is PROTOCOL_X; then flow2 (PeerC <-> PeerD) will be PROTOCOL_Y ``` To get optimal classification results, both flow1 and flow2 must be processed by the same local context. This is not an issue at all in the far most common scenario where there is only one local context, but it might be impractical in some more complex scenarios. Create the concept of "global context": multiple local contexts can use the same global context and share some data (structures) using it. This way the data correlating multiple flows can be read/write from different local contexts. This is an optional feature, disabled by default. Obviously data structures shared in a global context must be thread safe. This PR updates the code of the LRU implementation to be, optionally, thread safe. Right now, only the LRU caches can be shared; the other main structures (trees and automas) are basically read-only: there is little sense in sharing them. Furthermore, these structures don't have any information correlating multiple flows. Every LRU cache can be shared, independently from the others, via `ndpi_set_config(ndpi_struct, NULL, "lru.$CACHE_NAME.scope", "1")`. It's up to the user to find the right trade-off between performances (i.e. without shared data) and classification results (i.e. with some shared data among the local contexts), depending on the specific traffic patterns and on the algorithms used to balance the flows across the threads/cores/local contexts. Add some basic examples of library initialization in `doc/library_initialization.md`. This code needs libpthread as external dependency. It shouldn't be a big issue; however a configure flag has been added to disable global context support. A new CI job has been added to test it. TODO: we should need to find a proper way to add some tests on multithreaded enviroment... not an easy task... *** API changes *** If you are not interested in this feature, simply add a NULL parameter to any `ndpi_init_detection_module()` calls.
Powered by cgit, Themed by Ted Yin.