Bug 256587 - tcpreplay not working for if_tun (tun0)
Summary: tcpreplay not working for if_tun (tun0)
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-14 02:41 UTC by Michael F
Modified: 2024-04-20 12:12 UTC (History)
3 users (show)

See Also:


Attachments
Packet captures from reproducing this issue (cap1.pcap, cap3.pcap, loopback.pcap) (986 bytes, application/zip)
2021-06-14 02:41 UTC, Michael F
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael F 2021-06-14 02:41:04 UTC
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
Comment 1 Seth Hoffert 2023-10-22 17:56:27 UTC
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.
Comment 2 Seth Hoffert 2024-04-20 12:12:32 UTC
The pull request for this (#876) has been merged into the main branch.