Created attachment 225789 [details] Packet captures from reproducing this issue (cap1.pcap, cap3.pcap, loopback.pcap) This is a repeat of Bug #198211. It appears that one cannot send packets to an if_tun interface using /dev/bpf. This was previously considered a possibility in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198211#c1 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198211#c3, but it does not appear that any fix similar to https://cgit.freebsd.org/src/commit/?h=stable/10&id=71ee29ab93aed361d2718ed46c557eeb0bfd88b8 was applied to if_tun.c (now if_tuntap.c): https://cgit.freebsd.org/src/tree/sys/net/if_tuntap.c?h=stable/13#n1402 I think that applying the same fix to if_tuntap.c will fix this issue. ## Steps to reproduce: 1. Install tcpreplay with: pkg install tcpreplay 2. Start up a tunnel on tun0 where the remote side responds to ICMP echo requests. My tunnel was configured as: tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> inet 192.0.2.1 --> 192.0.2.2 netmask 0xffffff00 groups: tun nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Opened by PID 1144 3. Capture a trace on tun0: tcpdump -i tun0 -s 0 -n -w loopback.pcap 4. Generate some traffic on tun0: eg: ping -c3 192.0.2.2 5. Stop the capture, it should have some ICMP packets inside 6. Monitor traffic on tun0: tcpdump -i tun0 -s 0 -n -X 7. Replay the ICMP traffic with: tcpreplay --intf1=tun0 loopback.pcap ## Expected behaviour: * All ICMP packets are correctly replayed through tun0 ## Actual behaviour: * One packet is sent with af=31 (pseudo_AF_HDRCMPLT), which is invalid (see attached cap1.pcap) * tcpreplay reports several warnings: Warning: Unable to process unsupported DLT type: BSD loopback (0x0) Warning: Unable to send packet: Error with bpf send() [1]: Address family not supported by protocol family (errno = 47) ## Attachments (in tun-tcpreplay.zip) * cap1.pcap: packet capture at reproduction step 5, using tun0 – a single packet is sent out the tun0 interface with af=31 * cap3.pcap: packet capture reproduction at step 5, but using lo0 – this looks correct, but still issues the "unsupported DLT type" warning * loopback.pcap: packet capture at reproduction step 2 using tun0 – three pairs of ICMP Echo requests and replies 192.0.2.1 -> 192.0.2.2 ## Versions: * FreeBSD 13.0 RELEASE on amd64 * tcpdump 4.9.3 * libpcap 1.9.1 * tcpreplay 4.3.3
FYI, I'm taking this on as part of https://github.com/freebsd/freebsd-src/pull/876 and also took the opportunity to make other interfaces consistent as well.
The pull request for this (#876) has been merged into the main branch.
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3f6515c20f381d6e136c8c322eadc69fd0e6c4aa commit 3f6515c20f381d6e136c8c322eadc69fd0e6c4aa Author: Seth Hoffert <seth.hoffert@gmail.com> AuthorDate: 2023-10-22 14:12:45 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2024-05-08 13:06:15 +0000 bpf: Make BPF interop consistent with if_loop The pseudo_AF_HDRCMPLT check is already being done in if_loop and just needed to be ported over to if_ic, if_wg, if_disc, if_gif, if_gre, if_me, if_tuntap and ng_iface. This is needed in order to allow these interfaces to work properly with e.g., tcpreplay. PR: 256587 Reviewed by: markj MFC after: 2 weeks Pull Request: https://github.com/freebsd/freebsd-src/pull/876 (cherry picked from commit 2cb0fce24d64039090dc9243cdf0715ee80c91b1) sys/dev/iicbus/if_ic.c | 4 ++-- sys/dev/wg/if_wg.c | 3 ++- sys/net/if_disc.c | 2 +- sys/net/if_gif.c | 3 ++- sys/net/if_gre.c | 3 ++- sys/net/if_me.c | 3 ++- sys/net/if_tuntap.c | 2 +- sys/netgraph/ng_iface.c | 2 +- 8 files changed, 13 insertions(+), 9 deletions(-)