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

[Thomas Lamprecht]

On 04.02.21 11:15, Mira Limbeck wrote:
> 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 at 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.
> 

OK, yeah just an idea.

But, I'd still like to see more code getting moved out from main.rs in it's own module,
ideally with only the relevant stuff being "pub".