History log of /haiku/src/add-ons/kernel/network/devices/tunnel/tunnel.cpp
Revision Date Author Comments
# 98166ebe 15-Feb-2024 Augustin Cavalier <waddlesplash@gmail.com>

network: Do not apply ethernet headers for loopback devices.

This reverts large portions of e2b57695fc3ec43cad099ab3dd93bdd99e052761
and all of 4e9653027d9094f4d57fd294d46ce6eb461b697f, and adjusts
the "tunnel" and "loopback_frame" handlers appropriately.

Initially, this logic was added so that libpcap continued working;
however, it seems that we can change some of the Haiku-specific code
in libpcap and have it continue to operate without requiring such
ethernet headers to be appended.

Fixes #18801.

Change-Id: Ie06908affde894ad1516fbc27e06298309a4e082
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7403
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>


# 819c5108 28-Dec-2023 Augustin Cavalier <waddlesplash@gmail.com>

network: Update device statistics (mostly) in the stack.

We bypass device logic in datalink_send_routed_data() in the case
of RTF_LOCAL, so if we don't update the stats there, they'll never
get updated. Furthermore, there's places packets can be dropped
inside the device reader thread. So, we might as well consolidate
the stats-updating logic and get it out of drivers.

(The only remaining case where drivers need to update stats is when
they drop a packet in receive(), as the stack can't tell when an error
from receive() is due to a dropped packet or not.)

Fixes a potential leak on packet drops in the device reader thread,
and fixes loopback statistics for TCP/UDP/etc.


# 71522c93 18-Nov-2023 François Revol <revol@free.fr>

net: Rename IFT_TUN to IFT_TUNNEL as on BSD

We already use their value, let's use the name too.

Change-Id: I5afbd69923ae3b5e702dfb935a709c3069de5365
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7146
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: François Revol <revol@free.fr>


# b6c24e6b 24-Nov-2023 Augustin Cavalier <waddlesplash@gmail.com>

network: Overhaul TUN/TAP subsystem.

* Rename the "tun" network device to "tunnel". FreeBSD calls theirs
"tuntap" but speaks of both TUN and TAP devices as interfaces for
tunnels. The other BSDs seem to do likewise.

* Fold the "tun" driver into the "tunnel" network device. The
network device now publishes entries in devfs when interfaces
are created, and unpublishes them when interfaces are destroyed.

This removes the need for the driver and device to communicate
through a file descriptor, and thus allows the receive queue
to be totally eliminated, massively simplifying that logic.

* Use standard net-stack FIFOs instead of TCP BufferQueue, which is
specialized to TCP's needs in far too many ways. Thanks to the
previous commit adding support for interrupting semaphore waits,
we can use the FIFO wait mechanisms, too.

* Restructure the TAP logic, and generate MAC addresses more like
Linux does.

* Actually set type = IFT_TUN, and use the "loopback" frame handler
instead of the "ethernet" frame handler. This allows significant
cleanup of the header handling logic.

* In TUN mode, reject packets that don't look like IP packets.

* Delete "tunconfig"; it was mostly stubs and is now unnecessary.

TUN mode tested and confirmed as working by kallisti5 with OpenVPN.
TAP mode partially tested, but not yet confirmed as working.

Fixes #18673.

Change-Id: Ibd803139474e8db556a4f567901da15ee4083621
Reviewed-on: https://review.haiku-os.org/c/haiku/+/7143
Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>