Date: Sat, 12 Jun 2004 16:16:17 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Vlad GALU <dudu@diaspar.rdsnet.ro> Cc: freebsd-net@freebsd.org Subject: Re: tun(4) issues Message-ID: <Pine.NEB.3.96L.1040612161207.90086N-100000@fledge.watson.org> In-Reply-To: <20040612082817.A10245@qvnfcne.eqfarg.eb>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040612161207.90086N-100000>