>> dev_t dev = makedev(40, i); // from MAKEDEV :(
>
> 40 is incorrect. It is MD.
>
> /usr/src/etc/etc.alpha/MAKEDEV: M tun$U c 7 $U 600
> /usr/src/etc/etc.amd64/MAKEDEV: M tun$U c 40 $U 600
Thanks, guess I'd better use system("cd /dev; sh MAKEDEV tunX");
> dev_t dev = makedev(40, i); // from MAKEDEV :(
40 is incorrect. It is MD.
/usr/src/etc/etc.alpha/MAKEDEV: M tun$U c 7 $U 600
/usr/src/etc/etc.amd64/MAKEDEV: M tun$U c 40 $U 600
/usr/src/etc/etc.armish/MAKEDEV:M tun$U c 33 $U 600
/usr/src/etc/etc.aviion/MAKEDEV:M tun$U c 23 $U 6
> unit = 13;
>if ((fd = open("/dev/tun0", O_RDONLY)) == -1)
>err(1, "failed to open /dev/tun0");
>if (ioctl(fd, TUNSIFUNIT, &unit) == -1)
>err(1, "ioctl failed");
I like it. I've got a few questions from npppd and openvpn users hitting the 4
t
Reyk Floeter wrote:
>On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis
> wrote:
>> But currently /dev/tunN is usable from any programming language that
>> that can do reads and writes. With Reyk's changes you need to do an
>> ioctl even for basic usage, which is at best quirky in languages
>other
On Thu, Nov 29, 2012 at 11:05 PM, Mark Kettenis wrote:
>> #!/usr/bin/perl
>> require "sys/ioctl.ph";
>> $TUNSIFUNIT = _IOC(&IOC_INOUT, ord('t'), 90, 4);
>> open(TUN0, "+> ioctl(TUN0, $TUNSIFUNIT, $unit = pack("i", -1)) or die "ioctl $!";
>> print "Returned: tun".unpack("i", $unit)."\n";
>> close(T
Penned by Reyk Floeter on 20121129 6:33.47, we have:
| On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov wrote:
| >> But currently /dev/tunN is usable from any programming language that
| >> that can do reads and writes. With Reyk's changes you need to do an
| >> ioctl even for basic usage, which
> Date: Thu, 29 Nov 2012 00:12:39 +0100
> From: Reyk Floeter
>
> On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis
> wrote:
> > But currently /dev/tunN is usable from any programming language that
> > that can do reads and writes. With Reyk's changes you need to do an
> > ioctl even for basic us
> My favourite "quick-and-dirty" language is Python, and I consider
> myself a fairly proficient Python programmer. I've never, ever, done
> ioctls from Python, and while it looks indeed as if it is possible to
> do so, I'm sure it'd take me some effort to get it right.
I definitely agree with yo
> Date: Thu, 29 Nov 2012 13:33:47 +0100
> From: Reyk Floeter
>
> btw., I like C and it is still my favorite language (sorry, CS
> people). But it shouldn't be a problem to do simple ioctls with most
> other languages except shell scripts.
>
> #!/usr/bin/perl
> require "sys/ioctl.ph";
> $TUNSIFUN
On 11/29/2012 01:33 PM, Reyk Floeter wrote:
> On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov wrote:
>>> But currently /dev/tunN is usable from any programming language that
>>> that can do reads and writes. With Reyk's changes you need to do an
>>> ioctl even for basic usage, which is at best q
On Thu, Nov 29, 2012 at 01:33:47PM +0100, Reyk Floeter wrote:
> On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov wrote:
> >> But currently /dev/tunN is usable from any programming language that
> >> that can do reads and writes. With Reyk's changes you need to do an
> >> ioctl even for basic usag
On Thu, Nov 29, 2012 at 10:59 AM, Mike Belopuhov wrote:
>> But currently /dev/tunN is usable from any programming language that
>> that can do reads and writes. With Reyk's changes you need to do an
>> ioctl even for basic usage, which is at best quirky in languages other
>> than C/C++. That fee
On 2012/11/28 22:21, Mike Belopuhov wrote:
> >> Drawback: This diff would require to patch all the existing users of
> >> /dev/tun* in ports and the tree to add the TUNSIFUNIT ioctl. The
> >> benefit is that you don't have to MAKEDEV all the tuns anymore and can
> >> open up to around 1024 active
On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis wrote:
>> From: Mike Belopuhov
>> Date: Wed, 28 Nov 2012 22:21:07 +0100
>>
>> On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis
>> wrote:
>> >> Date: Wed, 28 Nov 2012 17:39:24 +0100
>> >> From: Reyk Floeter
>> >>
>> >> Hi,
>> >>
>> >> inspired by mi
On Wed, Nov 28, 2012 at 10:42 PM, Mark Kettenis wrote:
> But currently /dev/tunN is usable from any programming language that
> that can do reads and writes. With Reyk's changes you need to do an
> ioctl even for basic usage, which is at best quirky in languages other
> than C/C++. That feels li
On Wed, Nov 28, 2012 at 1:42 PM, Mark Kettenis wrote:
> But currently /dev/tunN is usable from any programming language that
> that can do reads and writes. With Reyk's changes you need to do an
> ioctl even for basic usage, which is at best quirky in languages other
> than C/C++. That feels lik
> From: Mike Belopuhov
> Date: Wed, 28 Nov 2012 22:21:07 +0100
>
> On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis
> wrote:
> >> Date: Wed, 28 Nov 2012 17:39:24 +0100
> >> From: Reyk Floeter
> >>
> >> Hi,
> >>
> >> inspired by mikeb@'s clonable bpf patch, this slightly more complex
> >> diff im
On Wed, Nov 28, 2012 at 8:21 PM, Mark Kettenis wrote:
>> Date: Wed, 28 Nov 2012 17:39:24 +0100
>> From: Reyk Floeter
>>
>> Hi,
>>
>> inspired by mikeb@'s clonable bpf patch, this slightly more complex
>> diff implements clonable interface support to tun(4).
>>
>> The idea is to split the fixed re
> Date: Wed, 28 Nov 2012 17:39:24 +0100
> From: Reyk Floeter
>
> Hi,
>
> inspired by mikeb@'s clonable bpf patch, this slightly more complex
> diff implements clonable interface support to tun(4).
>
> The idea is to split the fixed relation between device minor number
> (/dev/tunX) and interfac
Hi,
inspired by mikeb@'s clonable bpf patch, this slightly more complex
diff implements clonable interface support to tun(4).
The idea is to split the fixed relation between device minor number
(/dev/tunX) and interface unit (ifconfig tunY). In difference to the
current tun(4) implementation, op
20 matches
Mail list logo
