Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 2 Aug 2021 19:23:46 +0200
From:   Pali =?utf-8?B?Um9ow6Fy?= <pali@kernel.org>
To:     Guillaume Nault <gnault@redhat.com>
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: How to find out name or id of newly created interface
Message-ID: <20210802172346.yj3ia7czg6o7kgn7@pali>
References: <20210731203054.72mw3rbgcjuqbf4j@pali>
 <20210802100238.GA3756@pc-32.home>
 <20210802105825.td57b5rd3d6xfxfo@pali>
 <20210802134320.GB3756@pc-32.home>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210802134320.GB3756@pc-32.home>
User-Agent: NeoMutt/20180716
Precedence: bulk

On Monday 02 August 2021 15:43:20 Guillaume Nault wrote:
> On Mon, Aug 02, 2021 at 12:58:25PM +0200, Pali Rohár wrote:
> > On Monday 02 August 2021 12:02:38 Guillaume Nault wrote:
> > > 
> > > So the proper solution is to implement NLM_F_ECHO support for
> > > RTM_NEWLINK messages (RTM_NEWROUTE is an example of netlink handler
> > > that supports NLM_F_ECHO, see rtmsg_fib()).
> > 
> > Do you know if there is some workaround / other solution which can be
> > used by userspace applications now? And also with stable kernels (which
> > obviously do not receive this new NLM_F_ECHO support for RTM_NEWLINK)?
> 
> I unfortunately can't think of any clean solution. It might be possible
> to create the new interface with attributes very unlikely to be used by
> external programs and retrieve the interface name and id by monitoring
> link creation messages (like 'ip monitor' does). But at this point it's
> probably easier to just set the interface name and retry with a
> different name every time it conflicted with an existing device.

"set interface name and retry" is what I'm using now... And looks like
it is the only stable solution for now.

I was already thinking about monitoring link creation messages... if
there is not some stable message ordering (e.g. order of response and
monitor message) but I have not deduced anything from the code.

> Maybe someone else could propose less hacky solutions, but I really
> can't think of anything else apart from implementing NLM_F_ECHO.