tun(4) issues

[Robert Watson]

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 at fledge.watson.org      Senior Research Scientist, McAfee Research