Page MenuHomeFreeBSD

tuntap: Add netmap support for both tap(4) and tun(4) interfaces
Changes PlannedPublic

Authored by markj on Mar 10 2023, 3:26 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Jun 7, 12:33 AM
Unknown Object (File)
Wed, May 22, 4:37 AM
Unknown Object (File)
Wed, May 22, 2:53 AM
Unknown Object (File)
Wed, May 22, 2:47 AM
Unknown Object (File)
Sun, May 19, 2:09 AM
Unknown Object (File)
Sat, May 18, 1:34 PM
Unknown Object (File)
May 14 2024, 5:10 PM
Unknown Object (File)
May 9 2024, 10:37 PM

Details

Summary

tap(4) works unmodified, whereas tun(4) needs some special logic to
insert and remove Ethernet headers, as tun(4) handles only IPv4 and v6
packets.

Obtained from: OPNsense

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 50523
Build 47414: arc lint + arc unit

Event Timeline

markj requested review of this revision.Mar 10 2023, 3:26 PM
  • Remove unneeded softc member addition.
  • Fix the proto check in tunwrite_netmap(): we get a netisr index, not a protocol family.

What is the use case for this change?
(Netmap was not originally supposed to work with L3 interfaces)

It looks artificial to hardcode MAC addresses... We should ensure a sane behaviour.
What if a netmap application forwards packets between netmap:tun0 and netmap:em0 (for example using the bridge program)? The fake MAC addresses will go on the wild..., and the packet wouldn't be received by anyone (unless a NIC really has that fake dst MAC address).
Or what if we attach netmap:tun0 and netmap:tun1 to a VALE switch? The learning bridge algorithm would flip because there are two members that produce Ethernet packets with the same source address.
Shouldn't we actually assign a pseudorandom MAC address to the tun interface, in the same way we do for tap (ether_gen_addr)?
And shouldn't we use ff:ff:ff:ff:ff:ff as a fake destination address, so that we play better with forwarding?

share/man/man4/tun.4
353

if that's what you meant

What is the use case for this change?
(Netmap was not originally supposed to work with L3 interfaces)

It looks artificial to hardcode MAC addresses... We should ensure a sane behaviour.
What if a netmap application forwards packets between netmap:tun0 and netmap:em0 (for example using the bridge program)? The fake MAC addresses will go on the wild..., and the packet wouldn't be received by anyone (unless a NIC really has that fake dst MAC address).
Or what if we attach netmap:tun0 and netmap:tun1 to a VALE switch? The learning bridge algorithm would flip because there are two members that produce Ethernet packets with the same source address.
Shouldn't we actually assign a pseudorandom MAC address to the tun interface, in the same way we do for tap (ether_gen_addr)?
And shouldn't we use ff:ff:ff:ff:ff:ff as a fake destination address, so that we play better with forwarding?

I'm sorry for the delay. These are all good suggestions, yes, and we found that there's another problem in that the TUNSIFHEAD and TUNSLMODE ioctls will cause all received packets to be prepended with a pseudo-header that will confuse netmap applications which examine L3 protocol info. TUNSIFHEAD is used by, e.g., openvpn. So now I'm not sure that adding netmap support here is viable at all.

No worries.

The question would indeed be: are there meaningful use cases for using netmap:tunX? If not, I would avoid this patch.

In any case, you would at least ensure that those TUNSIFHEAD and TUNSLMODE are rejected if netmap is on, and that netmap:tunX cannot be opened if those modes are set.

The use case: a number of VPN software solutions like OpenVPN use this driver so the idea was to be able to grab traffic off of the interface before encryption/after decryption. It looks like tun may not be worth the effort, but it could work for tap mode without further constraints?

tap mode is supposed to work unmodified... I've not tried on FreeBSD, but on Linux it definitely works.