On Wed, Apr 29, 2009 at 10:14:05AM -0400, James Carlson wrote:
> Anders Persson writes:
> > As most of you already know, if_nameindex(3SOCKET) and
> > if_indextoname(3SOCKET) will only return physical device names. It
> > also appears that some applications expect that the interface names
> > obtained using the API will be usable for issuing lifreq ioctls.
> > However, if you are using the API in a non-global zone that only has
> > logical interfaces, things break down as the zone cannot issue ioctls
> > on interfaces that are not in the zone (so
> > if_nametoindex(if_indextoname(1)) == 0 :-).
> >
> > What do you guys think about the idea of changing if_nameindex() and
> > if_indextoname() such that they return logical names when the
> > physical ones are not accessible?
>
> That seems reasonable as a work-around. At one point, we talked about
> allowing vanity names up at the IP level so that shared stack
> non-global zones could have less ugly interface names, and I think
> that'd help with this problem, but the idea never went anywhere.
Yup. :-/
> If we're concerned about safety, we could make it so that the new
> logic is invoked only if getzoneid() != GLOBAL_ZONEID.
Seems like a good precaution. My biggest concern when looking at this
is for applications that expect the name obtained from
if_indextoname() to be that of a physical device. One example in ON is
ifconfig when it's dealing with usesrc. So in a zone:
# ifconfig -a
...
e1000g0:2: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 3
usesrc e1000g1:1
inet 192.168.3.1 netmask ffffff00 broadcast 192.168.3.255
e1000g1:1: flags=1000802<BROADCAST,MULTICAST,IPv4> mtu 1500 index 4
srcof e1000g0
inet 192.168.2.1 netmask ffffff00 broadcast 192.168.2.255
e1000g2:2 ...
A more common scenario might be converting the index obtained from a
routing socket message to a name. So it seems like there can be an
impact on usability, and code in ON would have to be updated to handle
logical names (i.e. convert them to physical if that's what they want).
Thoughts?
Anders
_______________________________________________
networking-discuss mailing list
[email protected]
