From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ESics+dv; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id B437F5A004E for ; Thu, 23 Jan 2025 13:25:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737635156; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xCw83Yv711crocVBeWDh7mveVjTBJhDqAMtMS20kavU=; b=ESics+dvj1TI9b38uQtyDUWhtgt3K6FTXkYAVBGmMNa0SWt+NM+/AlJlKbbJo9VmruRq3O B78xDSMMArPS0BF7s9zIMF23HfxMq2uhzG1Ae9Y8YrPgd+Fbw2Qh08vN584aPxcwOB2Pec 2VlJaXn/zRfUGOiOy7OkCMizmJk3qVo= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-561-LXPp67EbN4OXAVCOw7DMRg-1; Thu, 23 Jan 2025 07:25:53 -0500 X-MC-Unique: LXPp67EbN4OXAVCOw7DMRg-1 X-Mimecast-MFC-AGG-ID: LXPp67EbN4OXAVCOw7DMRg Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-385e49efd59so356714f8f.0 for ; Thu, 23 Jan 2025 04:25:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737635153; x=1738239953; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xCw83Yv711crocVBeWDh7mveVjTBJhDqAMtMS20kavU=; b=gKVN3c1WC9I4PqFycYSrltsNPytbvHFdkJiAiVeO3ufS2Yse35tiNzyT3+AT8Lt4+Y LO6uq6HvWVqsjXou/AbdJ+Xbu0fhdr699Qd1EEjYXWSrl8PDKvUp1n+xISx3AUr7z9Dc iis0NzMBEJLi0ij3ex5zgulIhM8NZPFB3SVYIcVaGI+53zTu9JrMcnc9q3/wSikf7zjy o6cjtwNK6xjQKFqNkpKhxxifHXacC70U1tzphWHUThZcoTvS9X4xsq/3PpOAT3gfnpK7 stdIQcqnMjqWMUIfZXerWu9TsQO/PQrDIKsEE1hQMUrDbJIPtDd3ELPPiAxFhMmRNqRl mBtQ== X-Gm-Message-State: AOJu0YxEl1FSTErm3hM2H3sweQr8R8qOW0D98zYxSm4yiRAZWWKUnr9m bpDuz3uuQZgtwPhd57CjwXZXuCJTMJO4FKvy9N4xwwJtt4DpmxTTxUtVpwT/Dsfqr+IrFjfE5tD Wxh4ydlL5Up+uChW3ayHy8x1HAntFV3uvpKLN6AwbK0n9KvNHlQ== X-Gm-Gg: ASbGnctn8LXVLZUsycfkGaBe0KbhrYXqx2p8hwbIhhXRGPPg8+fW7IrgcPxlToRqCTU w3upM+SLrZmgvXXRWB9eLtA4Bl47b4iEyHLNYpxAc2v4tZ8pb0NTmoQh8d5lQkPIQXCfHA4VtG+ acQ2B3C9p0boF2xEHVaEdKKygVtB5vMkGXgA8ZB0UOHqSr1PKJMxVMVVXYdayaEZnGMO7/AbOY4 8TM1Q41rNUCvIG5Oy2Z1NDLpBNPuel2wlAU9ShOw8o0g54T3aGHVh2fDMOcTGfyf/2chxyzwvU= X-Received: by 2002:a05:600c:5012:b0:434:9e46:5bc with SMTP id 5b1f17b1804b1-438913ca718mr267151145e9.10.1737635152702; Thu, 23 Jan 2025 04:25:52 -0800 (PST) X-Google-Smtp-Source: AGHT+IEYWy75pM5tfdWXwZjNfWOOCMLg01KmcnukqehKhS2hNVajLPX3oPz3HLdidiKJjw6INbnX8w== X-Received: by 2002:a05:600c:5012:b0:434:9e46:5bc with SMTP id 5b1f17b1804b1-438913ca718mr267150935e9.10.1737635152360; Thu, 23 Jan 2025 04:25:52 -0800 (PST) Received: from [192.168.188.25] ([80.243.52.134]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438b31a2f1csm59600145e9.16.2025.01.23.04.25.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jan 2025 04:25:51 -0800 (PST) Message-ID: <2160ada2-dd2f-49f0-8361-47f8028118c5@redhat.com> Date: Thu, 23 Jan 2025 13:25:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] netlink: Skip loopback interface while looking for a template To: Stefano Brivio References: <20250123080548.1410738-1-sbrivio@redhat.com> <07aa7b5d-27b9-4494-88db-d675b7489f68@redhat.com> <20250123125354.0d25b157@elisabeth> From: Paul Holzinger In-Reply-To: <20250123125354.0d25b157@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: ZAN5UnXTDr0Srb_wkVqiF-BoBaBHVyS0pzxqE0-zCWs_1737635153 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: GEBW6LR6BNE2UKLFW537GJSK6RG5JBH2 X-Message-ID-Hash: GEBW6LR6BNE2UKLFW537GJSK6RG5JBH2 X-MailFrom: pholzing@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 23/01/2025 12:53, Stefano Brivio wrote: > On Thu, 23 Jan 2025 12:49:06 +0100 > Paul Holzinger wrote: > >> On 23/01/2025 09:05, Stefano Brivio wrote: >>> There might be reasons to have routes on the loopback interface, for >>> example Any-IP/AnyIP routes as implemented by Linux kernel commit >>> ab79ad14a2d5 ("ipv6: Implement Any-IP support for IPv6."). >>> >>> If we use the loopback interface as a template, though, we'll pick >>> 'lo' (typically) as interface name for our tap interface, but we'll >>> already have an interface called 'lo' in the target namespace, and as >>> we TUNSETIFF on it, we'll fail with EINVAL, because it's not a tap >>> interface. >>> >>> Skip the loopback interface while looking for a template interface or, >>> more accurately, skip the interface with index 1. >>> >>> Strictly speaking, we should fetch interface flags via RTM_GETLINK >>> instead, and check for IFF_LOOPBACK, but interleaving that request >>> while we're iterating over routes is unnecessarily complicated. >> I think hard coding 1 is fine but I think there is also the IFF_LOOPBACK >> flag that could be used instead. >> >> From strace: >> ifi_index=if_nametoindex("lo"), >> ifi_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING|IFF_LOWER_UP > Yeah but that's in the link flags, right? Am I missing something? Here > we're looking at routes. > > Note that 'ip route show' will also fetch link attributes with > RTM_GETLINK, which is the second netlink query I wanted to avoid here. Ah yes totally overlooked the fact the ip route does the RTM_GETLINK call there. -- Paul Holzinger