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.limb...@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". _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
