aboutsummaryrefslogtreecommitdiff
path: root/tests/result/stun_signal.pcapng.out
Commit message (Collapse)AuthorAge
* 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
* STUN: fix "confidence" value for some classifications (#1407)Ivan Nardi2022-01-15
|
* 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.
* Improve/add several protocols (#1383)Ivan Nardi2021-12-18
Improve Microsoft, GMail, Likee, Whatsapp, DisneyPlus and Tiktok detection. Add Vimeo, Fuze, Alibaba and Firebase Crashlytics detection. Try to differentiate between Messenger/Signal standard flows (i.e chat) and their VOIP (video)calls (like we already do for Whatsapp and Snapchat). Add a partial list of some ADS/Tracking stuff. Fix Cassandra, Radius and GTP false positives. Fix DNS, Syslog and SIP false negatives. Improve GTP (sub)classification: differentiate among GTP-U, GTP_C and GTP_PRIME. Fix 3 LGTM warnings.