On Thu, Oct 25, 2007 at 11:03:56AM -0200, Marcus Andree wrote: > comments inline. > > On 10/25/07, Michael <[EMAIL PROTECTED]> wrote: > > Hi, > > > > thanks for your fast answer. > > > > Marcus Andree schrieb: > > > Maybe you'll have to compile a new kernel. There's an options(4) option > > > called tun. I had to add something like > > > > > > pseudo-device tun 16 > > > > I read something while googling for this issue that you had to add > > something like that for older versions of OpenBSD like before 3.6 or > > even 3.4. > > > > Yep. It was some time ago.... ;) > > > > on a kernel config file once. If I remember correctly, the default is the > > > kernel > > > to allocate 4 tun channels. That would explain why it's failing in the > > > 5th QEMU > > > guest. > > > > > > Don't forget that customized kernels aren't "supported". > > > > Well, more than 4 tun interfaces ARE working ... if I create /dev/tun4 > > or higher manually with (cd /dev; ./MAKEDEV tun4) and also manually add > > tun4 to the bridge (brconfig bridge0 add tun4 up) ... but QEMU does that > > for tun0 - tun3 on its own ... its just not working for more than the > > first four interfaces. > > > By stating that the interfaces ARE working, you mean that they not only > exist but the bridges are correctly configured and functional, right? >
It is possible to use more then 4 tun(4) interfaces. No porblems. > If more than 4 tun devices work properly on the openbsd-side, then this > thing should be a qemu issue, be it fixable from an external shell > script or not. > Looks like an issue with the if-up shell script or qemu. > > Btw, would something like > > > > ![ -c /dev/tun4 ] || (cd /dev; ./MAKEDEV tun4) > > > > work inside a /etc/hostname.tun4 file, just to make sure the device exists? > > > > I'd prefer to work directly with mknod than cd'ing to /dev and firing up > MAKEDEV > to create just one character device. > Bad idea. The major number of tun is paltform dependent. Calling MAKEDEV is by far better. -- :wq Claudio
