On 03/05/2010 10:39:26 AM, Gert Doering wrote:
> Hi,
>
> On Fri, Mar 05, 2010 at 11:44:28AM +0100, Heiko Hund wrote:
> > On Friday 05 March 2010 10:11:51 Gert Doering wrote:
> > > What happened exactly? Could you ask your colleague for a log
> file?
> >
> > Well, he couldn't ping any remote host. Nothing special in the log,
> really. If
> > it isn't misleading it's quite obvious that the ordering is wrong:
> >
> > TUN/TAP device /dev/tun1 opened
> > /sbin/ifconfig tun1 destroy
> > /sbin/ifconfig tun1 create
> > NOTE: Tried to delete pre-existing tun/tap instance --No Problem
> if failure
> > /sbin/ifconfig tun1 10.1.1.18 10.1.1.17 mtu 1500 netmask
> 255.255.255.255 up
>
> Well, this is exactly what the current code for NetBSD does... (and
> how
> this thread got started). On NetBSD, it works.
>
> The problem is that if you do it the other way round, you have a big
> fat
> race condition here - between "I assume that my tun device will be
> tun1,
> so I do 'ifconfig tun1 destroy' now" and actually opening /dev/tun1,
> some other process might grab this tun device.
>
> open() first will exclusively lock it for you...
From OpenBSD's tun(4) man page:
Each device has the exclusive open property; it cannot be
opened if it is
already open and in use by another process.
...
On the last close of the device, all queued packets are
discarded. If the device was created by opening /dev/tunN,
it will be
automatically destroyed. Devices created via ifconfig(8) are
only marked
as not running and traffic will be dropped returning EHOSTDOWN.
Which means to me that you want to omit the ifconfig destroy and
create, thus:
TUN/TAP device /dev/tun1 opened with open(2)
/* iterate increasing tunN number until you get other than
* EBUSY (the device was already opened), or suchlike searching */
/sbin/ifconfig tun1 10.1.1.18 10.1.1.17 mtu 1500 netmask \
255.255.255.255 up
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
