tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Interface type

On Wed, Sep 10, 2008 at 06:16:14PM +0100, Roy Marples wrote:
> On Wed, 2008-09-10 at 18:27 +0200, Quentin Garnier wrote:
> > On Wed, Sep 10, 2008 at 06:16:27PM +0200, Martin Husemann wrote:
> > > On Wed, Sep 10, 2008 at 05:06:30PM +0100, Roy Marples wrote:
> > > > 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.

> 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.

> 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

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.

> 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.

Quentin Garnier - -
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpTvOFltHcCX.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index