From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> 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 5924C6D1B9 for <pve-devel@lists.proxmox.com>; Thu, 4 Feb 2021 11:20:34 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 50766227F9 for <pve-devel@lists.proxmox.com>; Thu, 4 Feb 2021 11:20:34 +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 7AAF5227EC for <pve-devel@lists.proxmox.com>; Thu, 4 Feb 2021 11:20:33 +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 447E24617B for <pve-devel@lists.proxmox.com>; Thu, 4 Feb 2021 11:20:33 +0100 (CET) Message-ID: <f3b709c8-1dcb-bb15-2e77-c6cf37802da5@proxmox.com> Date: Thu, 4 Feb 2021 11:20:32 +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: Mira Limbeck <m.limbeck@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20210203142536.28480-1-m.limbeck@proxmox.com> <8bc0c730-c3e9-1395-a6af-1f1934840192@proxmox.com> <56f3e87a-27f8-6672-3fa3-fad3bd495e0a@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <56f3e87a-27f8-6672-3fa3-fad3bd495e0a@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.473 Adjusted score from AWL reputation of From: address CTE_8BIT_MISMATCH 0.998 Header says 7bits but body disagrees 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. [crates.io, main.rs, mnl.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 <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 04 Feb 2021 10:20:34 -0000 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@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".