Re: Specifying names for tap interfaces

[Darren Reed <darrenr%netbsd.org@localhost>]

On 24/06/2012 4:28 AM, Manuel Bouyer wrote:
> On Sun, Jun 24, 2012 at 03:55:54AM +1000, Darren Reed wrote:
>> On 24/06/2012 1:13 AM, Manuel Bouyer wrote:
>>>> Yes, but you're a developer.
>>>> Not everyone is a developer.
>>>
>>> Administrators can understand this too. Users usually don't deal with
>>> interface names directly, they use some high-level tool.
>>
>> Such as?
> 
> I don't know, I'm an admin, I use ifconfig and route :)
> But I know there are graphical tools out there to manage network. 
> I just don't use them.

And if they're not bundled with NetBSD, how will they ever
work with labels if labels require special fields be used?

>> One of the more useful pieces of information available from
>> lanscan is the "Path". This represents the device tree to
>> which the network interface is connected. Thus it is easier
>> to determine if "wm2" is on the same piece of hardware as "wm0",
> 
> This would be drvctl's job. This is the kind of informations you may want
> to any device, not only network interface.

Some of that information, yes, but other aspects of it, no.
drvctl shouldn't inherit network specific tasks or outputs
just like it shouldn't do so for disk.

Presently we have dkctl for disks but there is no analogue for
network devices.

However the primary task here would be to make that information
available. Once that is done then it is a simpler matter of
writing some tools to either extract it directly or layer on
top of drvctl.

>> NetBSD needs to seriously look at the command set for network
>> interface administration and enhance the model beyond being
>> centered around ifconfig.
>>
>> Trying to keep shoe horning everything into ifconfig is just
>> going to make ifconfig more and more unwieldly as time goes by.
> 
> This is possible. I don't care much as long as I get the infos I want.

Which information do you need/want?

>>> It's just a matter of what we want to provide as primary information:
>>> proxy0 or wm6. As proxy0 could also be
>>> some_very_long_name_because_there_s_lot_of_interfaces
>>> then I think we should stay with wm6 as the primary information
>>> (or output of things like netstat will be awfull).
>>
>> Why should wm6 be the primary thing used in output?
>>
>> If you want to encourage people to use some other name when
>> doing various network administration tasks then why shouldn't
>> they see it used in output?
>>
>> For example, if I do:
>>
>> ifconfig newprojectvlan0 192.168.1.1/24 up
>>
>> and then do
>>
>> netstat -nrf inet
>>
>> then if I don't see a "192.168.1.0/24" route in the routing
>> table next to "newprojectvlan0",  I'm going to be awfully
>> confused.
> 
> You won't see "newprojectvlan0", you'll see "newprojectv". This is
> a typical example where long names will be a problem. For anything that
> uses a tabular display, you need short names.

"Need" short names?

Is there something holy about the tabular display that means it
can't shift to allow longer fields? Notice the behaviour of vmstat
for one. Does it start truncating fields because a line gets too
long? No. IPv6 broke the 80 column barrier long ago for netstat
so there should be no sentimental feelings for that any longer.

>> Being able to use both the label and some other name for
>> the network interface simultaneously will end up just creating
>> confusion because there will be some instances where you can
>> use the label and some where you can't,
> 
> If there are place where it can't this has to be fixed

So you have already said that the network interface should
only be used on output but here you're arguing the reverse?

Additionally this goes back to the 3rd party software issue.

>> some where it is
>> output and some where it isn't.
> 
> No: the interface name should always be used for output, not the label.

This is a bad model. The same name should always be available
to be used with administration tools regardless if it is for
output or input. No ifs or buts. If that isn't possible then
something else new is needed.

What you're proposing is now sounding more like an alias, not
a label, because an alias is typically a one way mapping of
one name to another.

To put some more light on this, what you're saying is that
the administration model would be like this:

# ifconfig label,proxy 1.2.3.4
# netstat -nrf inet | grep wm6

I can't see how NetBSD could accept that kind of administration
model for network interfaces. If you can rename interfaces then
the following is possible:

# ifconfig proxy0 1.2.3.4
# netstat -nrf inet | grep proxy0

and that is a whole lot more sensible.

>> And none of those decisions
>> about where or when it is or isn't used will be under the
>> user's control.
>>
>> In light of that, if a more meaningful name for a network
>> device is desired, it is simpler in every way for there to
>> be one name that is used everywhere and to provide the means
>> to not only assign the name to a device but to also see what
>> names have been assigned to what devices.
> 
> If some tools can't use "label,mylabelname" they're likely to also
> be problems with arbitrary interface names.

Not likely.

By creating a naming mechanism that uses something other
than if_xname to store the interface name in, the cost of
porting networking software to NetBSD properly goes up
unless this would be a feature that nothing in pkgsrc used.

If arbitrary names are allowed through renaming and those
names are always presented in struct ifnet with if_xname
then there should be no problems as long as the name
complies with the expected format of <name><number>.

Darren