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
Differential D39015
tuntap: Add netmap support for both tap(4) and tun(4) interfaces markj on Mar 10 2023, 3:26 PM. Authored by Tags None Referenced Files
Details tap(4) works unmodified, whereas tun(4) needs some special logic to Obtained from: OPNsense
Diff Detail
Event TimelineComment Actions
Comment Actions What is the use case for this change? It looks artificial to hardcode MAC addresses... We should ensure a sane behaviour.
Comment Actions 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. Comment Actions 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. Comment Actions 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? Comment Actions tap mode is supposed to work unmodified... I've not tried on FreeBSD, but on Linux it definitely works. |