From owner-freebsd-net@FreeBSD.ORG Sat Jun 12 20:17:41 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A19416A4CE for ; Sat, 12 Jun 2004 20:17:41 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DBE943D2D for ; Sat, 12 Jun 2004 20:17:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5CKGHS0095803; Sat, 12 Jun 2004 16:16:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5CKGHCj095800; Sat, 12 Jun 2004 16:16:17 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 12 Jun 2004 16:16:17 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Vlad GALU In-Reply-To: <20040612082817.A10245@qvnfcne.eqfarg.eb> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: tun(4) issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2004 20:17:41 -0000 On Sat, 12 Jun 2004, Vlad GALU wrote: > Hello. I've been trying to set up a VPN server which should > serve a large number of clients. Let's say something between 500 and > 1000. I'd like to use the tun interface to do it. Now, what I observed > when I tried to create 1000 tun devices, was that their minor numbers > started to cycle every once in a while. So I guess there are replicas of > my initial tun devices. Am I wrong ? Anyway, I only see these repeating > minor numbers when browsing /dev/ from midnight commander. 'ls' shows a > whole different kind of minor numbers, written in hex. Casting those to > integers results in way larger numbers than usual, for example 196610. > > Before I start testing, am I doing something wrong here ? Should > I stop now and find another implementation ? > > Thanks in advance for any feedback. Are you sure that minor numbers are duplicated? You shouldn't see that, and if you do, it's a bug. However, the observation regarding numbers and a non-contiguous shift to hex should be correct. This is because, historically, the device number was 16-bit: 8 bits for major number, 8 bits for minor number. When the device number was extended to 32-bit, the bits allocated to the minor number became non-contiguous. Here are the conversion routines to turn the device number into the parts: #define minor(x) ((int)((x)&0xffff00ff)) /* minor number */ #define major(x) ((int)(((u_int)(x) >> 8)&0xff)) /* major number */ I.e., minor numbers go from 0 to 255 (0x00 - 0xff), then skip all values with non-zero third and fourth digits in hex. I.e.: ... crw------- 1 uucp dialer 233, 254 May 25 13:26 /dev/tun254 crw------- 1 uucp dialer 233, 255 May 25 13:26 /dev/tun255 crw------- 1 uucp dialer 233, 0x00010000 May 25 13:26 /dev/tun256 crw------- 1 uucp dialer 233, 0x00010001 May 25 13:26 /dev/tun257 ... So assuming you're not actually seeing duplicate minor numbers or collisions, it should be operating correctly. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research