--- Begin Message ---On May 8, 2020, at 10:47 AM, Guy Harris via tcpdump-workers <tcpdump-workers@lists.tcpdump.org> wrote:> No, nobody appears to have contributed a change to add support to > epan/dissectors/packet-sll.c yet. I just did; it was a significant enough change to a bit of infrastructure used by other dissectors that it's probably not a candidate for backporting, but it should show up in the 3.4 release, which should come out some time this year. The main clients of libpcap on Linux are probably: 1) tcpdump - already supports SLL2 in the main branch, so will be supported in 5.0; 2) Wireshark - now supports SLL2 in the main branch, so will be supported in 3.4; 3) some others - Snort? Scapy? Bro^WZeek? Any other ideas? Snort and its daq library, as of the latest release tarballs understand SLL but not SLL2. Snort3/Snort++ and its daq library appear to understand neither in the master branch. Scapy appears to understand SLL but not SLL2 in the master branch. Zeek appears to have a tiny bit of understanding of SLL but not SLL2 in the master branch; it might be that it runs with a filter such as "ip" or "ip or ip6", so all it needs to know is how to skip over the link-layer header, which it does. So, for now, I guess defaulting to SLL2 in tcpdump is the best answer, as it won't surprise any other software's live capture. If new versions of various Linux distribution come out with the new tcpdump at about the same time as the new Wireshark comes out, it shouldn't cause problems with Wireshark reading tcpdump captures.
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
