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 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. > 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 - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "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