Date: Fri, 29 Jul 2005 21:01:30 -0700 From: Maksim Yevmenkin <maksim.yevmenkin@savvis.net> To: Bsderss <snort_sam@yahoo.com> Cc: freebsd-questions@freebsd.org Subject: Re: why tun/tap but instead ordinary ethernet device (eg. fxp) Message-ID: <42EAFB9A.4080309@savvis.net> In-Reply-To: <20050730032019.5480.qmail@web54406.mail.yahoo.com> References: <20050730032019.5480.qmail@web54406.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42EAFB9A.4080309>