Hi,
On Thu, Feb 07, 2019 at 01:39:39PM +0100, Michal Kubecek wrote:
> On Thu, Feb 07, 2019 at 01:27:28PM +0100, Phil Sutter wrote:
> > On Thu, Feb 07, 2019 at 11:24:38AM +0100, Phil Sutter wrote:
> > > Align interface name handling regarding alias interfaces in
> > > rtnl_getlink() with dev_ioctl() treating SIOCGIFINDEX ioctl calls. The
> > > latter function strips any colon suffix before doing the interface
> > > lookup, do the same for RTM_GETLINK requests.
> >
> > After a second thought, I'll self-NACK this one: Given that netlink API
> > is completely unrelated to ioctl one, there is no inherent need to do
> > things the same way. Looking at RTM_NEWLINK handler, it seems possible
> > to create interface names containing a colon via netlink.
>
> Not since commit a4176a939186 ("net: reject creation of netdev names
> with colons") which disallowed using such names in general.
In my typical afterthought I tried 'ip link add d0:1 type dummy' and was
surprised to get EINVAL from kernel side. Just discovered that line in
dev_valid_name(), too.
> But I still don't think it would be a good idea. It's bad enough that
> (as I just learned to my surprise) "ip link del dummy1:0" deletes dummy1
> without any complaint because ip uses SIOCGIFINDEX ioctl for ifindex
> lookup.
I'm struggling a bit with all this. The original problem is iproute2
commit 50b9950dd9011 ("link dump filter") which changed 'ip link show'
to not use if_indextoname() when given just an interface name. So lookup
happens by name (via RTM_GETLINK) and consequently 'ip link show eth0:1'
doesn't give link stats of eth0 anymore.
Given that iproute2 is supposed to be backwards compatible, the only
valid option I see is to make sure netlink API calls like the above
behave identical to the ioctl ones they replace. Which means allowing
for 'ip link show eth0:42' even if there's no address with that label
assigned to eth0 as well as your example above.
Cheers, Phil
