Closed glebius closed 1 year ago
Update: actually just adding DLT_NULL as alias for DLT_RAW works, if --no-flow-stats is also specified.
Update 2: actually removing assertion from flow_decode() is enough to get it working.
Thanks for PR #733.
I got a similar message from tcpreplay 4.3.3-2+b1
(Debian 11 - bullseye):
Warning in flows.c:flow_decode() line 258:
Unable to process unsupported DLT type: BSD loopback (0x0)
Displaying encapsulation (capinfos and editcap come from tshark package):
capinfos -E DLT0x0.pcap
File encapsulation: NULL/Loopback
Workaround:
# change encapsulation type to ethernet
editcap -T ether DLT0x0.pcap good.pcap
(posting here in hope to find it later when stuck on tcpreplay 4.3.x)
Starting with 16442ac3b2791df0e0a08034240834daad7c7a12 tcpreplay can no longer replay packets on a loopback interface.
Previous behavior:
After 16442ac3b2791df0e0a08034240834daad7c7a12:
>/usr/src/tcpreplay/src/tcpreplay -i lo0 /tmp/1syn.pcap
The operating system is FreeBSD 14. The loopback has type DLT_NULL and tcpreplay has always been known to not recognize it. However, since DLT_NULL doesn't need any special handling tcpreplay just worked on lo0, albeit printing a warning. With that in mind I quickly hacked get_l2_len_protocol() to just accept DLT_NULL. Unfortunately this wasn't enough. Looks like upper stack of the code is now all designed about Ethernet. That is unfortunate, cause sending on loopback is useful functionality that allows to build unit tests with tcpreplay to be run in a virtual environment.