| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
If the flow is classified (via DPI) after the first packet, we should
use this information as FPC
|
| |
|
|
| |
Add printing of fpc_dns statistics and add a general cconfiguration option.
Rework the code to be more generic and ready to handle other logics.
|
| |
|
|
|
|
|
|
|
| |
Use DNS information to get a better First Packet Classification.
See: #2322
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
| |
|
|
|
| |
Let's start with some basic helpers and with FPC based on flow addresses.
See: #2322
|
| |
|
|
|
| |
Since 070a0908b we are able to detect P2P calls directly from the packet
content, without any correlation among flows
|
| |
|
|
|
| |
Support rtp/rtcp over tcp as per rfc4571.
Signed-off-by: mmaatuq <mahmoudmatook.mm@gmail.com>
|
| |
|
| |
The original code handled also TCP/TLS, but it was removed in 6fc29b3ae
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
other_address parsing
Added code to ignore invalid STUN realm
Extended JSON output with STUN information
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Clean up Steam dissector
* Add Steam Datagram Relay dissector
* Update docs
* Update test results
* Remove csgo.c from MSVC project
* Small fixes
* Add Steam TLS pcap sample
* Merge Steam pcap samples into single one
* Fix typo
* Update test results
|
| | |
|
| | |
|
| |
|
| |
Increment the counter only if the flow has been guessed
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Try to have a faster classification, on first packet; use standard extra
dissection data path for sub-classification, metadata extraction and
monitoring.
STUN caches:
* use the proper confidence value
* lookup into the caches only once per flow, after having found a proper
STUN classification
Add identification of Telegram VoIP calls.
|
| | |
|
| |
|
| |
Fix the script to download crawler addressess
|
| |
|
|
|
|
| |
Jabber/XMPP is only over TCP (even the name `ndpi_search_jabber_tcp`
suggests that...).
Bug introduced in 5266c726f
|
| | |
|
| |
|
|
|
|
|
| |
as explained here for bitcoin https://www.ntop.org/guides/nDPI/protocols.html#ndpi-protocol-bitcoin
the same is applicable for ethereum.
ethereum detection was removed from mining protocol and is now handled separately.
Signed-off-by: Mahmoud Maatuq <mahmoudmatook.mm@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
Regardless of the name, the removed trace doesn't contain meaningful
Hangout traffic.
Remove last piece of sub-classifiction based only on ip addresses.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This piece of code has multiple problems:
* nDPI is able to detect some TCP protocols even with mid-flows (i.e.
without the initial packets of the session); TLS is the most
significative example
* since e6b332aa4a1399e33df68998cf8351bccaee3fc4 it is perfectly valid
to not pass the TCP Handshake packets to nDPI
* in any case, we shouldn't call `ndpi_detection_giveup()`. That
function is usually called by the application and we end up calling it
twice in some cases.
The simple solution is to completely remove that code: process these
kinds of flows like everyone else.
Note that the application can always avoid to pass to nDPI any TCP flows
without the initial handshake; the flow managemnt is always up to the
application.
Looking at the CI results, some rare flows are now processed significantly
longer. As a follow-up we could look into that.
|
|
|
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`
|