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

[markj]

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

[markj]

• Remove unneeded softc member addition.
• Fix the proto check in tunwrite_netmap(): we get a netisr index, not a protocol family.

[vmaffione]

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

[markj]

In D39015#892936, @vmaffione wrote:

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.

[vmaffione]

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.

[franco_opnsense.org]

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?

[vmaffione]

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