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

Thomas Lamprecht t.lamprecht at proxmox.com
Thu Feb 4 11:20:32 CET 2021

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".

More information about the pve-devel mailing list