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

[Maksim Yevmenkin]

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