Auf Linuxsystemen gibt es das /dev/net/tun, welches kurz in linux/Documentation/networking/tuntab.rst beschrieben ist.
Aufmerksam darauf bin ich durch Studium von QEMU.
Hier ist unser Versuch tun.tgz
Übersetzt und startet man das Programm tuntest, so erscheint bei ip addr oder ifconfig -a ein Networkdevice tun0.
Dann konfigurieren wir eine IP-Addresse und Route:
ifconfig tun0 10.0.5.1 netmask 255.255.255.0 up
(Alternativ kann man dies auch mit dem beigelegten Programm netconfig machen. Da hat mich interessiert, welche Systemcalls ifconfig aufruft.
Natürlich kann man die beiden Programme kombinieren.)
Nun kann man Netzwerkaktivitäten machen wie
ping 10.0.5.1
oder mit multicastv4.tgz:
sender -l 15 -n 10 10.0.5.1
Auf der stdout von tuntest sieht man folgende Ausgabe:
sizeof(TunFrame)=4 52 bytes read Flags=0 Proto=34525 (flags=0 proto=56710) ihl=0 version=6 protocol=128 src=0.0.0.0 dest=235.136.82.191 52 bytes read Flags=0 Proto=34525 (flags=0 proto=56710) ihl=0 version=6 protocol=128 src=0.0.0.0 dest=235.136.82.191 52 bytes read Flags=0 Proto=34525 (flags=0 proto=56710) ihl=0 version=6 protocol=128 src=0.0.0.0 dest=235.136.82.191 88 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=1 src=10.0.5.1 dest=10.0.5.2 88 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=1 src=10.0.5.1 dest=10.0.5.2 88 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=1 src=10.0.5.1 dest=10.0.5.2 88 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=1 src=10.0.5.1 dest=10.0.5.2 88 bytes read 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 47 bytes read Flags=0 Proto=2048 (flags=0 proto=8) ihl=5 version=4 protocol=17 src=10.0.5.1 dest=10.0.5.2 52 bytes read
Wir sehen ipv6-Pakete vom NDP, die werden hier mit angezeigt, die Destination-addresse ist nicht richtig decodiert.
Bei UDPv4 - Protocol 17 stimmt die Src- und Destinationaddr, wie auch beim ipv4-ping.
Wir sehen also, dass jedes Netzwerkpaket im read(2)-Systemcall aus dem Device ankommt.
Dies ist ein Experimentierprogramm, das vollstädige Programm ist die Linux-Portierung des uC OS. Dort haben wir ein Tunnelinterface zum Test des TCP/IP-Stack gebaut.
Symetrisch kann man mit write(2) Pakete auf das Netzwerk schicken. Die uC-OS-Instanz pingt und UDP dann.