From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 173D56D07C for ; Thu, 4 Feb 2021 09:08:03 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 078AA21465 for ; Thu, 4 Feb 2021 09:07:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id DABF621456 for ; Thu, 4 Feb 2021 09:07:31 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id A189E4616D for ; Thu, 4 Feb 2021 09:07:31 +0100 (CET) Message-ID: <8bc0c730-c3e9-1395-a6af-1f1934840192@proxmox.com> Date: Thu, 4 Feb 2021 09:07:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Thunderbird/86.0 Content-Language: en-US To: Proxmox VE development discussion , Mira Limbeck References: <20210203142536.28480-1-m.limbeck@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20210203142536.28480-1-m.limbeck@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.025 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.178 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [mnl.rs, main.rs] Subject: Re: [pve-devel] [PATCH conntrack-tool v2 1/5] initial commit X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2021 08:08:03 -0000 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 > --- > 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?