Interface type

[Roy Marples]

Hi List

Is there anyway to work out interface type?
IFF_POINTOPOINT exists for ppp links, but what about things like tunnels
and other virtual interfaces?

Basically I'm trying to automate a preference based on interface type.

The order I want is basically
loopback > PPP > tunnel -> wired -> wireless

Working out if it's a tunnel is the missing step in my code!

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roy Marples
The order I want is basically
loopback > PPP > tunnel -> wired -> wireless
Working out if it's a tunnel is the missing step in my code!

A tunnel is a point to point interface too, why do you want to tell them
apart?

You can tell wired from wireless by looking at the media type
(think "ifconfig $if | grep media:")

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Stephen Borrill]

Post by Martin Husemann

Post by Roy Marples
The order I want is basically
loopback > PPP > tunnel -> wired -> wireless
Working out if it's a tunnel is the missing step in my code!

A tunnel is a point to point interface too, why do you want to tell them
apart?
You can tell wired from wireless by looking at the media type
(think "ifconfig $if | grep media:")

Or look at the check in wiconfig.

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/wiconfig/wiconfig.c.diff?r1=1.39&r2=1.40&f=h

[Roy Marples]

Post by Stephen Borrill

Post by Martin Husemann
You can tell wired from wireless by looking at the media type
(think "ifconfig $if | grep media:")

Or look at the check in wiconfig.
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/wiconfig/wiconfig.c.diff?r1=1.39&r2=1.40&f=h

I already do this for wireless detection.
I was after how to find out that tap0 is a tunnel as opposed to the
physical interface bge0.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Roy Marples
[...]
I already do this for wireless detection.
I was after how to find out that tap0 is a tunnel as opposed to the
physical interface bge0.

tap0 is not (always) a tunnel; is depends on what the software running on the
other end is doing.

[Roy Marples]

Post by Martin Husemann

Post by Roy Marples
The order I want is basically
loopback > PPP > tunnel -> wired -> wireless
Working out if it's a tunnel is the missing step in my code!

A tunnel is a point to point interface too, why do you want to tell them
apart?

So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

Post by Martin Husemann
You can tell wired from wireless by looking at the media type
(think "ifconfig $if | grep media:")

I'm after ioctls, but I can already tell wireless from wired. :)
BTW, the ieee80211 man page is badly out of date as it just won't work
unless COMPAT stuff has been enabled in the kernel.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roy Marples
So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

tap(4) can be used in various ways, for example in a bridge(4) to provide
another MAC to run multiple pppoe(4) across a single external ethernet.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Quentin Garnier]

Post by Martin Husemann

Post by Roy Marples
So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

tap(4) can be used in various ways, for example in a bridge(4) to provide
another MAC to run multiple pppoe(4) across a single external ethernet.

The whole point of tap(4) is to be considered an Ethernet device for all
intents and purposes.

[Roy Marples]

Post by Quentin Garnier

Post by Martin Husemann

Post by Roy Marples
So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

tap(4) can be used in various ways, for example in a bridge(4) to provide
another MAC to run multiple pppoe(4) across a single external ethernet.

The whole point of tap(4) is to be considered an Ethernet device for all
intents and purposes.

Which still doesn't answer my question :)
Let me put it another way - given an interface name, can I find out if
it represents a physical device?

Let me be even more clear on what I want to achieve.
dhcpcd runs automatically, finds bge0 (wired) and iwi0 (wireless).
Both bge0 and iwi0 are attached to different subnets.
iwi0 comes up first, default route and /etc/resolv.conf is created.
Then bge0 comes up (laptop, plugged into LAN). dhcpcd will then change
the default route to go via bge0 and update /etc/resolv.conf with
nameservers from bge0 and then iwi0.
Once bge0 comes up, a VPN connects and dhcpcd configures that too.

So we now have a list of possible nameservers. Ideally we should
prioritize them like so
tap0 VPN
bge0 Wired
iwi0 Wireless

We should also prioritise the routing like so
bge0 Wired
iwi0 Wireless
tap0 VPN

Now, we could easily get the user to configure that in dhcpcd.conf, but
I would rather try and at least automate these defaults if at all
possible.

So again, is there an ioctl or not to work out if the interface is
tap(4) or virtual or physical.

If interface name aliasing goes through then we cannot rely on the name
of the interface as a guide.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Quentin Garnier]

Post by Roy Marples

Post by Quentin Garnier

Post by Martin Husemann

Post by Roy Marples
So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

tap(4) can be used in various ways, for example in a bridge(4) to provide
another MAC to run multiple pppoe(4) across a single external ethernet.

The whole point of tap(4) is to be considered an Ethernet device for all
intents and purposes.

Which still doesn't answer my question :)

Actually, it does. You just don't like the answer.

Post by Roy Marples
Let me put it another way - given an interface name, can I find out if
it represents a physical device?

Your problem is not whether or not it is a physical device. Your
problem is whether or not an interface depends on another. In the case
of OpenVPN, that program itself introduces the dependency between a tun
or a tap and another interface, and OpenVPN really is the only one that
can tell you about that dependency.

Post by Roy Marples
Let me be even more clear on what I want to achieve.
dhcpcd runs automatically, finds bge0 (wired) and iwi0 (wireless).
Both bge0 and iwi0 are attached to different subnets.
iwi0 comes up first, default route and /etc/resolv.conf is created.
Then bge0 comes up (laptop, plugged into LAN). dhcpcd will then change
the default route to go via bge0 and update /etc/resolv.conf with
nameservers from bge0 and then iwi0.
Once bge0 comes up, a VPN connects and dhcpcd configures that too.
So we now have a list of possible nameservers. Ideally we should
prioritize them like so
tap0 VPN
bge0 Wired
iwi0 Wireless
We should also prioritise the routing like so
bge0 Wired
iwi0 Wireless
tap0 VPN
Now, we could easily get the user to configure that in dhcpcd.conf, but
I would rather try and at least automate these defaults if at all
possible.

My feeling is that you will encounter some resistance if you try to
automate things too much in the NetBSD crowd (I'd probably be one not to
be happy about it; Windows trying to mess up with your interfaces
before you have the time to tell it what you really want always annoyed
me).

I think you should at least expect from the user to configure a list of
interfaces on which you are allowed to use dhcpcd automatically.

Post by Roy Marples
So again, is there an ioctl or not to work out if the interface is
tap(4) or virtual or physical.
If interface name aliasing goes through then we cannot rely on the name
of the interface as a guide.

Relying on the name of the driver is safe: if we ever add an ioctl to
rename an interface (something I welcome), we'll add one to query for
the driver name.

[David Young]

Post by Roy Marples

Post by Quentin Garnier

Post by Martin Husemann

Post by Roy Marples
So why does tap0 (which is a tunnel as used by OpenVPN) not have the
IFF_POINTOPOINT flag?

tap(4) can be used in various ways, for example in a bridge(4) to provide
another MAC to run multiple pppoe(4) across a single external ethernet.

The whole point of tap(4) is to be considered an Ethernet device for all
intents and purposes.

Which still doesn't answer my question :)
Let me put it another way - given an interface name, can I find out if
it represents a physical device?
Let me be even more clear on what I want to achieve.
dhcpcd runs automatically, finds bge0 (wired) and iwi0 (wireless).
Both bge0 and iwi0 are attached to different subnets.
iwi0 comes up first, default route and /etc/resolv.conf is created.
Then bge0 comes up (laptop, plugged into LAN). dhcpcd will then change
the default route to go via bge0 and update /etc/resolv.conf with
nameservers from bge0 and then iwi0.
Once bge0 comes up, a VPN connects and dhcpcd configures that too.
So we now have a list of possible nameservers. Ideally we should
prioritize them like so
tap0 VPN
bge0 Wired
iwi0 Wireless
We should also prioritise the routing like so
bge0 Wired
iwi0 Wireless
tap0 VPN
So again, is there an ioctl or not to work out if the interface is
tap(4) or virtual or physical.

Roy,

The short answer is "no."

Now that we got that out of the way. :-)

I think that a default interface prioritization may not be useful enough
to justify the size and complexity of implementing it in C in dhcpcd.

What if

1 the VPN alone gives me a stable, global IP number,
2 my wireless connection is stable as I walk from room to room
in my office, but
3 the ethernet jacks are not all on the same subnet

Speaking for myself, under those circumstances, I want the precise
opposite priority order to the one that you give above. I don't think
that it can be implemented by examining the interface type, alone.

Here is a thought: maybe you should prioritize leases instead of
interfaces?

Dave

[Roy Marples]

Post by David Young
Speaking for myself, under those circumstances, I want the precise
opposite priority order to the one that you give above. I don't think
that it can be implemented by examining the interface type, alone.

Right, the end user should always be able to control the exact ordering.
I'm just trying to get the sane-est default (in my mind, maybe not
yours) I possibly can.

Post by David Young
Here is a thought: maybe you should prioritize leases instead of
interfaces?

We already do - the exact criteria is carrier (up, unknown, down), then
lease (there or not) and finally metri (lower better, 100 + if_index,
+100 if wireless).

User can override metric in dhcpcd.conf or on the command line.

Thanks

Roy


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[der Mouse]

Post by Roy Marples
Let me put it another way - given an interface name, can I find out
if it represents a physical device?

"You can't".

Seriously, the question doesn't even really make all that much sense.
What exactly does it mean to "represent a physical device"? Does a
vlan interface represent a physical device? Does it depend on what its
vlanif setting is? What about an aggregator device? What about tap0
if it's being used with a suitable userland program to speak to, let's
say, a parallel-port ethernet device via /dev/lpt0? What about tap0 if
it's an OpenVPN tunnel? What about a Xen xvif interface? A Xen xennet
interface?

Depending on why you care, and in some cases other things not mentioned
above, the answers to each of those questions will vary. Network
interfaces as userland sees them are software fictions; the extent to
which they are backed by hardware is full of grey areas.

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de