This is automatically generated documentation. Edit after the "COMMENTS" heading; changes to the main body will be lost.
KernelTun -- Click element; interface to /dev/tun or ethertap (user-level)
KernelTun(ADDR/MASK [, GATEWAY, keywords HEADROOM, ETHER, MTU, IGNORE_QUEUE_OVERFLOWS])
Ports: at most 1 input, 1-2 outputs
Package: userlevel (core)
Reads IP packets from and writes IP packets to a /dev/net/tun, /dev/tun*, or /dev/tap* device. This allows a user-level Click to hand packets to the ordinary kernel IP processing code. KernelTun will also install a routing table entry so that the kernel can pass packets to the KernelTun device. KernelTun produces and expects IP packets. If, for some reason, the kernel passes up a non-IP packet (or an invalid IP packet), KernelTun will emit that packet on its second output, or drop it if there is no second output. KernelTun allocates a /dev/net/tun, /dev/tun*, or /dev/tap* device (this might fail) and runs ifconfig to set the interface's local (i.e., kernel) address to ADDR and the netmask to MASK. If a nonzero GATEWAY IP address (which must be on the same network as the tun) is specified, then KernelTun tries to set up a default route through that host. When cleaning up, KernelTun attempts to bring down the device via ifconfig. Keyword arguments are:
Make sure that your kernel has tun support enabled before running KernelTun. Initialization errors like "no such device" or "no such file or directory" may indicate that your kernel isn't set up, or that some required kernel module hasn't been loaded (on Linux, the relevant module is "tun"). On Linux and most BSDs, packets sent to ADDR will be processed by the host kernel stack; on Mac OS X there is no special handling for ADDR. Packets sent to any (other) address in ADDR/MASK will be sent to KernelTun. Say you run this configuration:
tun :: KernelTun(188.8.131.52/8); tun -> IPClassifier(icmp type echo) -> ICMPPingResponder -> IPPrint -> tun;
On Linux and most BSDs, if you then "
ping 184.108.40.206", your own kernel will respond:
Click will never see the packets, so it won't print anything.
But if you "
ping 220.127.116.11", the pings are sent to Click. You should see printouts from Click,
ping should print Click's responses.
This element differs from KernelTap in that it produces and expects IP
packets, not IP-in-Ethernet packets.
Generated by 'click-elem2man' from '../elements/userlevel/kerneltun.hh:10' on 12/Jul/2011.