aboutsummaryrefslogtreecommitdiff
path: root/tests/result/quic_interop_V.pcapng.out
Commit message (Collapse)AuthorAge
* Test multiple `ndpiReader` configurations (#1931)Ivan Nardi2023-04-06
| | | | | | | | | Extend internal unit tests to handle multiple configurations. As some examples, add tests about: * disabling some protocols * disabling Ookla aggressiveness Every configurations data is stored in a dedicated directory under `tests\cfgs`
* Add a new flow risk about literal IP addresses used as SNI (#1892)Ivan Nardi2023-03-02
| | | | | | | | | | RFC 6066 3: "Literal IPv4 and IPv6 addresses are not permitted in "HostName"." Don't set this risk if we have a valid sub-classification (example: via certificate) Since a similar risk already exists for HTTP hostnames, reuse it, with a more generic name.
* ndpiReader: print how many packets (per flow) were needed to perform full ↵Ivan Nardi2023-03-01
| | | | | | DPI (#1891) Average values are already printed, but this change should ease to identify regressions/improvements.
* Fix detection of packet direction and NDPI_UNIDIRECTIONAL_TRAFFIC risk (#1883)Ivan Nardi2023-02-13
|
* Shrinked symbolic flow risks labelsLuca Deri2023-01-19
|
* Remove some old protocols (#1832)Ivan Nardi2022-12-23
| | | | | | | | | | | | | | | | | | | | | These protocols: * have been addeded in the OpenDPI era * have never been updated since then * we don't have any pcap examples [*] If (and it is a big if...) some of these protocols are still somehow used and if someone is still interested in them, we can probably re-add them starting from scratch (because the current detection rules are probably outdated) Protocols removed: DIRECT_DOWNLOAD_LINK, APPLEJUICE, DIRECTCONNECT, OPENFT, FASTTRACK, SHOUTCAST, THUNDER, AYIYA, STEALTHNET, FIESTA, FLORENSIA, AIMINI, SOPCAST PPSTREAM dissector works (...) only on UDP. [*]: with do have an AIMINI test pcap but it was some trivial http traffic detected only by hostname matching, on domains no more available...
* STUN: add detection of ZOOM peer-to-peer flows (#1825)Ivan Nardi2022-12-11
| | | | See: "Enabling Passive Measurement of Zoom Performance in Production Networks" https://dl.acm.org/doi/pdf/10.1145/3517745.3561414
* TLS: improve handling of ALPN(s) (#1784)Ivan Nardi2022-10-25
| | | | | | | | Tell "Advertised" ALPN list from "Negotiated" ALPN; the former is extracted from the CH, the latter from the SH. Add some entries to the known ALPN list. Fix printing of "TLS Supported Versions" field.
* Fix value of `ndpi_protocol->protocol_by_ip`Nardi Ivan2022-09-25
| | | | Fix: a7c2734b
* Remove classification "by-ip" from protocol stack (#1743)Ivan Nardi2022-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Basically: * "classification by-ip" (i.e. `flow->guessed_protocol_id_by_ip` is NEVER returned in the protocol stack (i.e. `flow->detected_protocol_stack[]`); * if the application is interested into such information, it can access `ndpi_protocol->protocol_by_ip` itself. There are mainly 4 points in the code that set the "classification by-ip" in the protocol stack: the generic `ndpi_set_detected_protocol()`/ `ndpi_detection_giveup()` functions and the HTTP/STUN dissectors. In the unit tests output, a print about `ndpi_protocol->protocol_by_ip` has been added for each flow: the huge diff of this commit is mainly due to that. Strictly speaking, this change is NOT an API/ABI breakage, but there are important differences in the classification results. For examples: * TLS flows without the initial handshake (or without a matching SNI/certificate) are simply classified as `TLS`; * similar for HTTP or QUIC flows; * DNS flows without a matching request domain are simply classified as `DNS`; we don't have `DNS/Google` anymore just because the server is 8.8.8.8 (that was an outrageous behaviour...); * flows previusoly classified only "by-ip" are now classified as `NDPI_PROTOCOL_UNKNOWN`. See #1425 for other examples of why adding the "classification by-ip" in the protocol stack is a bad idea. Please, note that IPV6 is not supported :( (long standing issue in nDPI) i.e. `ndpi_protocol->protocol_by_ip` wil be always `NDPI_PROTOCOL_UNKNOWN` for IPv6 flows. Define `NDPI_CONFIDENCE_MATCH_BY_IP` has been removed. Close #1687
* Fix `ndpi_do_guess()` (#1731)Ivan Nardi2022-09-12
| | | | | Avoid a double call of `ndpi_guess_host_protocol_id()`. Some code paths work for ipv4/6 both Remove some never used code.
* Avoid useless host automa lookup (#1724)Ivan Nardi2022-09-05
| | | | | | | | | | | | | | | | | | | The host automa is used for two tasks: * protocol sub-classification (obviously); * DGA evaluation: the idea is that if a domain is present in this automa, it can't be a DGA, regardless of its format/name. In most dissectors both checks are executed, i.e. the code is something like: ``` ndpi_match_host_subprotocol(..., flow->host_server_name, ...); ndpi_check_dga_name(..., flow->host_server_name,...); ``` In that common case, we can perform only one automa lookup: if we check the sub-classification before the DGA, we can avoid the second lookup in the DGA function itself.
* Patricia tree, Ahocarasick automa, LRU cache: add statistics (#1683)Ivan Nardi2022-07-29
| | | | | | | | | | Add (basic) internal stats to the main data structures used by the library; they might be usefull to check how effective these structures are. Add an option to `ndpiReader` to dump them; enabled by default in the unit tests. This new option enables/disables dumping of "num dissectors calls" values, too (see b4cb14ec).
* Keep track of how many dissectors calls we made for each flow (#1657)Ivan Nardi2022-07-11
|
* Added unidirectional traffic flow riskLuca Deri2022-06-20
|
* Updated tests resultsLuca Deri2022-05-30
| | | | Code cleanup
* Modified risk labelsLuca Deri2022-05-04
|
* Sync unit tests results (#1533)Ivan Nardi2022-04-27
|
* Errors fixed (#1482)Vitaly Lavrov2022-03-08
| | | | | | | | | | | | | | | Fixed errors for bigendian platforms in ndpiReader. All address and port comparisons and hash calculations are done with endian in mind. The get_ndpi_flow_info() function searched for an existing flow for the forward and reverse direction of the packet. The ndpi_workflow_node_cmp() function looked for a flow regardless of the packet's direction. This is what led to an error in determining the direction of transmission of the packet. Fixed error in "synscan" test: the number of packets in the forward and reverse direction is incorrectly defined (verified via tcpdump). Fixed bug with icmp protocol checksum check for big endian platforms.
* Add few scripts to easily update some IPs lists (#1436)Ivan Nardi2022-02-09
| | | | | | | | | | | | | | | | | | | | | | | | * Add few scripts to easily update some IPs lists Some IPs lists should be updated frequently: try to easy the process. The basic idea is taken from d59fefd0 and a8fe74e5 (for Azure addresses): one specific .c.inc file and one script for each protocol. Add the possibility to don't load a specific list. Rename the old NDPI_PROTOCOL_HOTMAIL id to NDPI_PROTOCOL_MS_OUTLOOK, to identify Hotmail/Outlook/Exchange flows. TODO: ipv6 Remove the 9 addresses associated to BitTorrent: they have been added in e2f21116 but it is not clear why all the traffic to/from these ips should be classified as BitTorrent. * Added quotes * Added quotes Co-authored-by: Luca Deri <lucaderi@users.noreply.github.com>
* Improve protocol stacks (#1425)Ivan Nardi2022-01-30
| | | | | | | | | | | | | | | | | We should have two protocols in classification results only when the "master" protocol allows some sub-protocols. Classifications like `AmazonAWS`, `TLS/AmazonAWS`, `DNS/AmazonAWS` are fine. However classifications like `NTP/Apple`, `BitTorrent/Azure`, `DNScrypt.AmazonAWS` or `NestLogSink.Google` are misleading. For example, `ndpiReader`shows `BitTorrent/Azure` flows under `Azure` statistics; that seems to be wrong or, at least, very misleading. This is quite important since we have lots of addresses from CDN operators. The only drawback of this solution is that right now ICMP traffic is classified simply as `ICMP`; if we are really interested in ICMP stuff we can restore the old behaviour later.
* Sync unit tests results (#1423)Ivan Nardi2022-01-28
| | | Fix: 7a3aa41a
* Improved MicrosoftAzure detectionLuca Deri2022-01-12
|
* Add a "confidence" field about the reliability of the classification. (#1395)Ivan Nardi2022-01-11
| | | | | | | | | | | | | As a general rule, the higher the confidence value, the higher the "reliability/precision" of the classification. In other words, this new field provides an hint about "how" the flow classification has been obtained. For example, the application may want to ignore classification "by-port" (they are not real DPI classifications, after all) or give a second glance at flows classified via LRU caches (because of false positives). Setting only one value for the confidence field is a bit tricky: more work is probably needed in the next future to tweak/fix/improve the logic.
* Added Microsoft Azure supportLuca Deri2021-12-19
|
* ndpiReader: slight simplificaton of the output (#1378)Ivan Nardi2021-11-27
|
* Fixed cleartext protocol assignment (#1357)Ivan Nardi2021-10-25
|
* Refreshed results listLuca Deri2021-10-16
|
* Updated test results after latest commitLuca Deri2021-10-16
|
* Clode cleanup (after last merge)Luca Deri2021-08-08
|
* Added entropy calculation to check for suspicious (encrypted) payload. (#1270)Toni2021-08-08
| | | | | Signed-off-by: Toni Uhlig <matzeton@googlemail.com> Co-authored-by: Luca Deri <lucaderi@users.noreply.github.com>
* Updated outputLuca Deri2021-08-07
|
* Reworked flow risk implementationLuca Deri2021-07-23
|
* ndpiReader: add statistics about nDPI performance (#1240)Ivan Nardi2021-07-13
| | | | | | | The goal is to have a (roughly) idea about how many packets nDPI needs to properly classify a flow. Log this information (and guessed flows number too) during unit tests, to keep track of improvements/regressions across commits.
* Added flow risk scoreLuca Deri2021-05-18
|
* Added browser TLS heuristicLuca Deri2021-05-13
|
* Improved DGA detectionLuca Deri2021-03-03
| | | | | | | | Before Accuracy 66%, Precision 86%, Recall 38% After Accuracy 71%, Precision 89%, Recall 49%
* Improved DGA detection with trigrams. Disadvantage: slower startup timeLuca Deri2021-03-03
| | | | | Reworked Tor dissector embedded in TLS (fixes #1141) Removed false positive on HTTP User-Agent
* Restored QUIC statsLuca Deri2020-12-30
|
* Fixed output when tLS (nad not QUIC) is usedLuca Deri2020-12-28
|
* Quic fixes (#1067)Ivan Nardi2020-11-22
* QUIC: fix return value on error path on quic_cipher_init() * QUIC: allow dissection of sessions forcing version negotiation Enhance heuristic to avoid false positives.