| 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.
|
| |
|
|
|
| |
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
|
| |
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
* Add HL7 protocol dissector
* Small fixes
* Small fixes
|
| |
|
|
|
|
|
| |
* Add JSON-RPC protocol dissector
* Small fixes
* Improve detection
|
| |
|
| |
Increment the counter only if the flow has been guessed
|
| | |
|
| |
|
| |
Fix the script to download crawler addressess
|
| | |
|
| |
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The goal if to correlate the right request-response pair, exporting
metadata from only one transaction (for example, the right url & return
state pair)
As a nice side effect, the code should be much cleaner, but that is a
matter of taste.
Two differences respect to the previous code:
* as it happens in the CI, if in the flow there are only one response
(before) and one request (after), only the metadata of the response are
saved/exported
* for performance reasons, we don't call `ndpi_parse_packet_line_info()`
anymore for ALL packets triggering the HTTP dissector, but only for the
packets that we already know belong to an HTTP flow. This is the reason
for the changes in RTSP/SOAP/... code
|
| |
|