Re: [pve-devel] [PATCH conntrack-tool v2 1/5] initial commit

[Mira Limbeck <m.limbeck@proxmox.com>]

On 2/4/21 9:07 AM, Thomas Lamprecht wrote:
> On 03.02.21 15:25, Mira Limbeck wrote:
>> Dumping conntrack information and importing conntrack information works
>> for IPv4 and IPv6. No filtering is supported for now. pve-conntrack-tool
>> will always return both IPv4 and IPv6 conntracks together.
>>
>> Conntracks are serialized as JSON and printed on STDOUT line by line
>> with one line containing one conntrack. When inserting data is read
>> from STDIN line by line and expected to be one JSON object per line
>> representing the conntrack.
>>
>> Currently some conntrack attributes are not supported. These are
>> HELPER_INFO, CONNLABELS and CONNLABELS_MASK. The reason for this is that
>> handling of variable length attributes does not seem to be correctly
>> implemented in libnetfilter_conntrack. To fix this we would probably have
>> to use libmnl directly.
>>
>> Conntracks containing protonum 2 (IGMP) are ignored in the dump as
>> they can't be inserted using libnetfilter_conntrack (conntrack-tools'
>> conntrack also exhibits the same behavior).
>>
>> Expectation support, which is necessary for FTP and other protocols, is
>> not yet implemented.
>>
>> Signed-off-by: Mira Limbeck <m.limbeck@proxmox.com>
>> ---
>> v2:
>>   - changed Conntracks to Socket
>>   - reworked a lot of the code for less code duplication
>>   - reduced usage of 'unsafe'
>>   - added/changed things based on @Wobu's suggestions (off-list)
>>
>>   Cargo.toml                 |  14 ++
>>   src/main.rs                | 488 +++++++++++++++++++++++++++++++++++++
>>   src/mnl.rs                 | 132 ++++++++++
>>   src/netfilter_conntrack.rs | 168 +++++++++++++
>>   4 files changed, 802 insertions(+)
>>   create mode 100644 Cargo.toml
>>   create mode 100644 src/main.rs
>>   create mode 100644 src/mnl.rs
>>   create mode 100644 src/netfilter_conntrack.rs
>>
> I take a (very) quick look at it and the code itself seems quite sensible.
>
> One higher level question though, would it makes sense do have the whole
> plumbing and general socket interfacing in it's own library crate (or sub
> workspace or something like that) and the binary here separate and as
> plain user of that create.
>
> That way we could additionally publish it on crates.io, could be helpful
> form some people (even if conntrack/nl is certainly a bit of a niche).
>
> What do you think about that?

The bindings are not complete, I only added what I needed during 
development and sometimes a bit more.

We would have to remove the query_(conntracks|expects) and 
insert_(conntrack|expect) functions from the Socket then.


For libmnl there are already 2 crates available which provide a wrapper 
around the low level bindings: https://github.com/mullvad/mnl-rs and 
https://crates.io/crates/crslmnl which are more complete.

For netlink itself there are also some crates: 
https://crates.io/keywords/netlink

But I could not find any bindings for libnetfilter_conntrack.