Re: why tun/tap but instead ordinary ethernet device (eg. fxp)

• Previous message: Antoine Solomon: "onboard ethernet support"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 29 Jul 2005 21:01:30 -0700
To: Bsderss <snort_sam@yahoo.com>

Hello,

first, please _do_not_ cross post. second, please use appropriate
mailing list. i have redirected this thread to freebsd-questions@

>>this type of question comes up quite often. its
>>really simple: a single
>>read(2) call on /dev/tapX will return entire
>>ethernet frame (if any)
>>received by tap interface (minus ethernet crc). a
>>single write(2) call
>>on /dev/tapX will put entire ethernet frame (w/out
>>ethernet crc) onto
>>tap interface outgoing queue.
>>
>>so, the "buf" parameter to the write(2) call on
>>/dev/tapX device should
>>point to a buffer with *complete* ethernet frame,
>>including ethernet
>>header and payload. payload could be IP packet, but
>>it does not have to
>>be. any protocol that uses ethernet as transport can
>>be tunneled with
>>tap(4) (i.e. ipx).
>>
>>the above is true for tun(4) with exception that
>>tun(4) operates on IP
>>packets. so you have to write/read complete IP
>>packets to/from /dev/tun.
>
> Thanks for the detail explaination. As "man tap"
> pointed out, one can use tap drive as if using a pty
> device. I m not aware the obvious advantage of using
> tap over ordinarlly ethernet device for tunnelling
> programming (another example is ipsec). It may be
> because programming on tun/tap is alot of efficient
> and simpler. Can anyone pleaese explain?

tun(4)/tap(4) _do_not_ use pty(4) device. they provide functionality
similar to pty(4). you seem to be confused about about the concept, or
i'm not understanding your question.

the main purpose of the tun(4)/tap(4) is to provide _virtual_ network
interface, either ip only (tun) or ethernet (tap). the key word here is
/virtual/. both tun and tap are dual in their nature. on one side
network interface, on the other - character device. from the network
subsystem point of view the system has network interface (either ip or
ethernet), so you can assign ip address, netmask, routing etc. just like
with any other interface.

when the network subsystem sends packet out on the interface instead of
physically transmit packet over the wire tun/tap interface loopbacks it
back to the user space via character device. what you do with this
packet is up to you. openvpn and vtun encrypt the packet/shape it/etc.
and send it over another (physical) interface to the remote host. you
actually send the tun/tap packet as payload within another packet. the
remote system does the reverse. it extracts payload (tun/tap packet),
decrypts it, etc. and then writes it back into the character device.
this will put the packet on the tun/tap interface and the network
subsystem will think that is has received packet from the tun/tap interface.

another example is ppp daemon. ppp is a serial protocol, that is ip
packets are payload within ppp frames transmitted over the serial link.
what ppp daemon does is: it receives ppp frame over the serial link,
extract ip packet and writes it to the tun character device. the system
thinks that is has just received ip packet from the tun interface. when
the system sends ip packet out on the tun interface ppp daemon gets the
same packet from the character device, puts it into ppp frame and sends
it over the serial link. thus the system acts as if it was connected to
the ip network with the real interface, but in fact you do not even have
to have a network card (i.e. no real network interface).

> With vtun or openvpn, why they don't just simply use
> ordinary ethernet device driver but prefer tun or tap
> for tunneling or bridging network remote connection?
> Is it because applicaiton use tap or tun can send
> interrupt (with ioctl) to the remote client more
> efficiently? if so, can anyone please tell me what
> kind of efficiency does tun/tap over an ordianry
> ethernet device in terms of network programming?

tun/tap both have overhead, because you have to pass network packets
back and force between kernel and userspace. that is the downside. the
upside is simplicity and flexibility.

thanks,
max

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

• Previous message: Antoine Solomon: "onboard ethernet support"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]