[pve-devel] [PATCH conntrack-tool v2 1/5] initial commit
m.limbeck at proxmox.com
Thu Feb 4 11:15:13 CET 2021
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>
>> - 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:
But I could not find any bindings for libnetfilter_conntrack.
More information about the pve-devel