Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp8120889rdb; Thu, 4 Jan 2024 21:42:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IHKyQ1a/YelRgp8uk2iawenGGabq3buBNKAXXmu9m5Q+lZIfutg770+I4gdoQIiJQ85MrWq X-Received: by 2002:a05:620a:e06:b0:781:5872:786a with SMTP id y6-20020a05620a0e0600b007815872786amr1575868qkm.137.1704433324289; Thu, 04 Jan 2024 21:42:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704433324; cv=none; d=google.com; s=arc-20160816; b=AlpOXjjvxSjeTOYUmpMqwE7qSfXV27V05O/ip7k5cXN76VJucKPXB5OnAzBeDuUDtj rsTi1ZtrQhl2+e6J6ZM4aejYpq+x0byi8pd0mrOhMh87kQXEO1qQbhXhGltjXAOs3xvq NZTf5xae+IdFn5O4kH056/qRbRK8QDoff9NVjgU1MSLtw7ywfoAg9yGOXpiOXJM2WKqj XgrDvsx1j77doe9zRtaQRzBLYl8LT1l4WQwP84xAVJbjxY3Y1sAZP48l8bQmlEZREf8r ptNJHeaHl6TZGX/6kbvTpxZOYw4I2g/OaNtKLWJe/VJ2gEcknx2oRj73/Jnkj9XvIKXR Fzvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date:dkim-signature:dkim-filter; bh=ZHparnsAXqF4lWmx1ZSpxji42sUlAAumK+J8HFwwj/Y=; fh=++k+IL1GQYbnYgzQo26kDTYiAB7IGU6xSjkY381JD58=; b=K04IQ8+om8ucdGOugbWKCriOBC8HVbS4H7u9ZvFEdbBsIM1RjdoaQUi9zTIIsvYOv+ xRExQfY84mQfLfDOd0HEupvl80OySmo5FklvPob2MvLRdTa4FqerLNzGIdDqAJGG5asg +kcuMJdnVVSi5q9IkjyrH7KYuK+13VyotRK3y0wmzzxTe4lLbUIX9rDKCjM5ipivUE5E G2rvugtDnE4JmByJ12eF7jycMPqK2LYukTx4WmgfJe7JRVuC0p1HymHAcQF45rmAtm3H VUiBYWwoGnDCtzQNKvjoFfLeEe3qK9UVH3yZRRlKBWhdzGPUj8ed/OLhusTvG9NSMltB 8Jpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=sIMnf9mt; spf=pass (google.com: domain of linux-kernel+bounces-17488-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17488-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id h8-20020a05620a244800b0078185cdc6ddsi1167464qkn.445.2024.01.04.21.42.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Jan 2024 21:42:04 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17488-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=sIMnf9mt; spf=pass (google.com: domain of linux-kernel+bounces-17488-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17488-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0C0431C219D2 for ; Fri, 5 Jan 2024 05:42:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4F76B8C1C; Fri, 5 Jan 2024 05:41:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="sIMnf9mt" X-Original-To: linux-kernel@vger.kernel.org Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3FD1A610E; Fri, 5 Jan 2024 05:41:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Received: by linux.microsoft.com (Postfix, from userid 1134) id E257A20ACF15; Thu, 4 Jan 2024 21:41:53 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E257A20ACF15 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1704433313; bh=ZHparnsAXqF4lWmx1ZSpxji42sUlAAumK+J8HFwwj/Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=sIMnf9mtuKHXQ7pCG87+/a2xlA8gsERPHy6Y7GMfqcdL+adEw00Kv07zHEkJaXNLX 6fjHOinXlm/bimhEEdaFOFmtYQI+fZGUEZCh0Nf9Uq2XQKOFfnL/HmUvgP0b+GT8G3 1AZqPUbe7ckTTEHPk5rtEwtpyH0KfIZLkHVB2WlA= Date: Thu, 4 Jan 2024 21:41:53 -0800 From: Shradha Gupta To: Ani Sinha Cc: linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org, "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , Dexuan Cui , Long Li , Olaf Hering , Shradha Gupta Subject: Re: [PATCH v8] hv/hv_kvp_daemon:Support for keyfile based connection profile Message-ID: <20240105054153.GA18258@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <1696847920-31125-1-git-send-email-shradhagupta@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) On Sat, Dec 23, 2023 at 01:35:26PM +0530, Ani Sinha wrote: > On Sat, Dec 23, 2023 at 12:43???PM Ani Sinha wrote: > > > > On Fri, Oct 13, 2023 at 3:06???PM Ani Sinha wrote: > > > > > > > > > > > > > On 09-Oct-2023, at 4:08 PM, Shradha Gupta wrote: > > > > > > > > Ifcfg config file support in NetworkManger is deprecated. This patch > > > > provides support for the new keyfile config format for connection > > > > profiles in NetworkManager. The patch modifies the hv_kvp_daemon code > > > > to generate the new network configuration in keyfile > > > > format(.ini-style format) along with a ifcfg format configuration. > > > > The ifcfg format configuration is also retained to support easy > > > > backward compatibility for distro vendors. These configurations are > > > > stored in temp files which are further translated using the > > > > hv_set_ifconfig.sh script. This script is implemented by individual > > > > distros based on the network management commands supported. > > > > For example, RHEL's implementation could be found here: > > > > https://gitlab.com/redhat/centos-stream/src/hyperv-daemons/-/blob/c9s/hv_set_ifconfig.sh > > > > Debian's implementation could be found here: > > > > https://github.com/endlessm/linux/blob/master/debian/cloud-tools/hv_set_ifconfig > > > > > > > > The next part of this support is to let the Distro vendors consume > > > > these modified implementations to the new configuration format. > > > > > > > > Tested-on: Rhel9(Hyper-V, Azure)(nm and ifcfg files verified) > > > > > > Was this patch tested with ipv6? We are seeing a mix of ipv6 and ipv4 addresses in ipv6 section: > > > > There is also another issue which is kind of a design problem that > > existed from the get go but now is exposed since keyfile support was > > added. > > Imagine we configure both ipv6 and ipv4 and some interfaces have ipv4 > > addresses and some have ipv6. > > getifaddres() call in kvp_get_ip_info() will return a linked list per > > interface. The code sets ip_buffer->addr_family based on the address > > family of the address set for the interface. We use this to determine > > which section in the keyfile to use, ipv6 or ipv4. However, once we > > make this decision, we are locked in. The issue here is that > > kvp_process_ip_address() that extracts the IP addresses concatenate > > the addresses in a single buffer separating the IPs with ";". Thus > > across interfaces, the buffer can contain both ipv4 and ipv6 addresses > > separated by ";" if both v4 and v6 are configured. This is problematic > > as the addr_family can be either ipv4 or ipv6 but not both. > > Essentially, we can have a situation that for a single addr_family in > > hv_kvp_ipaddr_value struct, the ip_addr member can be a buffer > > containing both ipv6 and ipv4 addresses. Notice that > > process_ip_string() handles this by iterating through the string and > > for each ip extracted, it individually determines if the IP is a v6 or > > a v4 and adds "IPV6ADDR" or "IPADDR" to the ifcfg file accordingly. > > process_ip_string_nm() does not do that and solely makes the > > determination based on is_ipv6 values which is based on a single > > addr_family value above. Thus, it cannot possibly know whether the > > specific IP address extracted from the string is a v4 or v6. Unlike > > for ifcfg files, fir nm keyfiles, we need to add v4 and v6 addresses > > in specific sections and we cannot mix the two. So we need to make two > > passes. One for v4 and one for v6 and then add IPs in the respective > > sections. > > > > This issue needs to be looked into and unless it's resolved, we cannot > > support both ipv4 and ipv6 addresses at the same time. > > In the short term, we should probably do this to avoid the mismatch : > > diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c > index 318e2dad27e0..b77c8edfe663 100644 > --- a/tools/hv/hv_kvp_daemon.c > +++ b/tools/hv/hv_kvp_daemon.c > @@ -1216,6 +1216,9 @@ static int process_ip_string_nm(FILE *f, char > *ip_string, char *subnet, > subnet_addr, > (MAX_IP_ADDR_SIZE * > 2))) { > + if (is_ipv6 == is_ipv4((char*) addr)) > + continue; > + > if (!is_ipv6) > plen = kvp_subnet_to_plen((char *)subnet_addr); > else > > But this is really a short term hack. Thanks for bringing this up Ani. I will try to fix this in a new patch (would get the new testcases added in our suite as well)