| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hard limit of total number of protocols (internal and custom) is ~65535,
because protocol ids are `u_int16_t`...
API changes:
1. From `NDPI_MAX_SUPPORTED_PROTOCOLS + NDPI_MAX_NUM_CUSTOM_PROTOCOLS` to
`ndpi_get_num_protocols()` (after having called
`ndpi_finalize_initialization()`);
2. From `proto_id >= NDPI_MAX_SUPPORTED_PROTOCOLS` to
`ndpi_is_custom_protocol(proto_id)` (after having called
`ndpi_finalize_initialization()`);
Close #2136
Close #2545
|
|
|
| |
GLBP is a Cisco proprietary first-hop redundancy protocol similar to HSRP and VRRP, but with additional load balancing capabilities.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main difference is that the memory is allocated at runtime
Typical usercase:
```
struct ndpi_bitmask b;
ndpi_bitmask_alloc(&b, ndpi_get_num_internal_protocols());
ndpi_bitmask_set(&b, $BIT);
ndpi_bitmask_is_set(&b, $BIT);
[...]
ndpi_bitmask_dealloc(&b);
```
See #2136
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`ndpi_set_protocol_detection_bitmask2()` (#2853)
The main goal is not to have the bitmask depending on the total number
of protocols anymore: `NDPI_INTERNAL_PROTOCOL_BITMASK` depends only on
internal protocols, i.e. on `NDPI_MAX_INTERNAL_PROTOCOLS`, i.e.
custom-defined protocols are not counted.
See #2136
Keep the old data structure `NDPI_PROTOCOL_BITMASK` with the old
semantic.
Since we need to change the API (and all the application code...)
anyway, simplify the API: by default all the protocols are enabled.
If you need otherwise, please use `ndpi_init_detection_module_ext()`
instead of `ndpi_init_detection_module()` (you can find an example in
the `ndpiReader` code).
To update the application code you likely only need to remove these 3
lines from your code:
```
- NDPI_PROTOCOL_BITMASK all;
- NDPI_BITMASK_SET_ALL(all);
- ndpi_set_protocol_detection_bitmask2(ndpi_str, &all);
```
Removed an unused field and struct definition.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use `registr_dissector()` instead of
`ndpi_set_bitmask_protocol_detection()`.
Every file in `src/lib/protocols/*.c` is a dissector.
Every dissector can handle multiple protocols.
The real goal is this small change:
```
struct call_function_struct {
- NDPI_PROTOCOL_BITMASK detection_bitmask;
```
i.e. getting rid of another protocol bitmask: this is mandatory to try
to fix #2136 (see also e845e8205b68752c997d05224d8b2fd45acde714)
As a nice side effect, we remove a bitmask comparison in the hot function
`check_ndpi_detection_func()`
TODO: change logging configuration from per-protocol to per-dissector
|
| |
|
| |
|
|
|
|
|
|
| |
In the flow, we should keep track of state of "dissectors", not
"protocols". This way, flow structure doesn't depend anymore on
the max number of protocols.
This is also the first step into fixing #2136
|
| |
|
|
|
|
| |
This is the first, tiny, step into a better separation between
"protocols" and "dissectors"
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Remove the specific dissector and use the Blizzard's generic one.
For the time being, keep `NDPI_PROTOCOL_WORLDOFWARCRAFT`
|
|
|
|
|
| |
games (#2776)
Remove `NDPI_PROTOCOL_STARCRAFT` and add a generic `NDPI_PROTOCOL_BLIZZARD`.
|
|
|
|
|
|
| |
(#2773)
Remove `NDPI_PROTOCOL_MAPLESTORY` and add a generic
`NDPI_PROTOCOL_NEXON`
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
|
|
| |
See 6899f6c17 and 9bf513b34
|
| |
|
| |
|
|
|
|
| |
(#2618)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* Added missing free
* Win fix
|
| |
|
| |
|
|
|
|
|
| |
* Added ndpi_quick_encrypt() ndpi_quick_decrypt(0 APi calls based on AES
* Added aes.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Extended API with functions for vector similarity based on KD-trees https://en.wikipedia.org/wiki/K-d_tree
ndpi_kd_tree* ndpi_kd_create(u_int num_dimensions);
void ndpi_kd_free(ndpi_kd_tree *tree);
void ndpi_kd_clear(ndpi_kd_tree *tree);
bool ndpi_kd_insert(ndpi_kd_tree *tree, const double *data_vector, void *user_data);
ndpi_kd_tree_result *ndpi_kd_nearest(ndpi_kd_tree *tree, const double *data_vector);
u_int32_t ndpi_kd_num_results(ndpi_kd_tree_result *res);
bool ndpi_kd_result_end(ndpi_kd_tree_result *res);
double* ndpi_kd_result_get_item(ndpi_kd_tree_result *res, double **user_data);
bool ndpi_kd_result_next(ndpi_kd_tree_result *res);
void ndpi_kd_result_free(ndpi_kd_tree_result *res);
double ndpi_kd_distance(double *a1, double *b2, u_int num_dimensions);
|
| |
|
|
|
| |
The Train Real Time Data Protocol (TRDP) is a UDP/TCP-based communication protocol designed for IP networks in trains, enabling data exchange between devices such as door controls and air conditioning systems. It is standardized by the IEC under IEC 61375-2-3 and is not related to the Remote Desktop Protocol (RDP).
|
|
|
|
|
|
|
| |
See also #2523
---------
Co-authored-by: Nardi Ivan <nardi.ivan@gmail.com>
|
|
|
| |
ISO/IEC 14908-4 defines how to tunnel Control Network Protocol (CNP) over IP networks. It encapsulates protocols like EIA-709, EIA-600, and CNP, making it a versatile solution for building automation and control systems.
|
| |
|
| |
|
|
|
| |
See: #2484
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
|
|
| |
Signed-off-by: Toni Uhlig <matzeton@googlemail.com>
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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.
|