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? 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. > 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. > > Michael
