Re: [tcpdump-workers] LINUX_SLL2 printing update
--- Begin Message --- On May 8, 2020, at 9:57 PM, Francois-Xavier Le Bail via tcpdump-workers wrote: > For a quick look, I don't need 'ifindex N', but I need 'In/Out,...' > > Thus I propose to print: +1 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] LINUX_SLL2 printing update
--- Begin Message --- Hello, As a user, I think the current print with LINUX_SLL2 on the "any" interface is not optimal. tcpdump -nt: ifindex 2 (eth0) IP 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1098, seq 1, length 64 ifindex 2 (eth0) IP 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1098, seq 1, length 64 tcpdump -nte: ifindex 2 (eth0) Out 00:50:79:ab:cd:ef ethertype IPv4 (0x0800), length 104: 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 ifindex 2 (eth0) In 00:50:79:12:34:56 ethertype IPv4 (0x0800), length 104: 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 For a quick look, I don't need 'ifindex N', but I need 'In/Out,...' Thus I propose to print: tcpdump -nt: eth0 Out 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 eth0 In 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 tcpdump -nte: eth0 Out ifindex 2 00:50:79:ab:cd:ef ethertype IPv4 (0x0800), length 104: 192.168.1.1 > 9.9.9.9: ICMP echo request, id 1109, seq 1, length 64 eth0 In ifindex 2 00:50:79:12:34:56 ethertype IPv4 (0x0800), length 104: 9.9.9.9 > 192.168.1.1: ICMP echo reply, id 1109, seq 1, length 64 We can change because the printing is currently not supported in any release version, thus no usage/habit/greping really defined. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On May 8, 2020, at 10:47 AM, Guy Harris via tcpdump-workers 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
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 08/05/2020 22:59, Francois-Xavier Le Bail via tcpdump-workers wrote: >> > In fact, no need to change libpcap. Can be do in tcpdump code. >> >> > See: https://github.com/the-tcpdump-group/tcpdump/pull/850 >> >> definitely do this in tcpdump. > Done. So for tcpdump in current master, DLT_LINUX_SLL2 is the new default for the "any" interface with libpcap >= 1.9.1 (version 1.9.1 and libpcap in current master). -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 08/05/2020 19:59, Michael Richardson wrote: > > Francois-Xavier Le Bail via tcpdump-workers wrote: > >>> BTW how about DLT_LINUX_SLL2 as the default? What does it block? > > >> To avoid breaking program that cannot use SLL2, could we have an API > >> like pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() > >> and use it in tcpdump? > > > In fact, no need to change libpcap. Can be do in tcpdump code. > > > See: https://github.com/the-tcpdump-group/tcpdump/pull/850 > > definitely do this in tcpdump. Done. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail wrote: > To avoid breaking program that cannot use SLL2, Note, by the way, that one program that can't dissect LINKTYPE_LINUX_SLL2 packets is named "Wireshark". No, nobody appears to have contributed a change to add support to epan/dissectors/packet-sll.c yet.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On Mar 31, 2020, at 2:10 AM, Francois-Xavier Le Bail wrote: > On 31/03/2020 00:04, Petr Vorel wrote: >> Hi Guy, >> BTW man pages (pcap.3pcap.in, pcap_datalink.3pcap.in, pcap_loop.3pcap and pcap_next_ex.3pcap) mention only DLT_LINUX_SLL. >> >>> Fixed in commit ffb99eceefd31771a4aa89f0da5d02a3c53cfd03. >> Thanks a lot! >> >> BTW how about DLT_LINUX_SLL2 as the default? What does it block? > > To avoid breaking program that cannot use SLL2, could we have an API like > pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() and use it > in tcpdump? Or have an API like pcap_set_datalink() and use it in tcpdump. Which we already do: tcpdump -y LINUX_SLL -w /tmp/linux_sll_not_linux_sll2.pcap--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 15:39, Francois-Xavier Le Bail wrote: > On 07/05/2020 09:39, Francois-Xavier Le Bail via tcpdump-workers wrote: >>> In this *particular* case, that test is done only if the uppermost nibble >>> of the uppermost octet is 0, so that would only be the case for the source >>> address, which is less likely to be a group address than the destination >>> address. There may be other places where that heuristic dissector is used, >>> however. >> Ok. >> What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of >> ff:ff:ff:ff:ff:ff ? > > Currently tshark don't decode if first nibble is <> de 4, 6, 1, 0: > (ARP request not seen, just "Data") > --- > MultiProtocol Label Switching Header, Label: 262145, Exp: 0, S: 1, TTL: 253 > 0100 0001 = MPLS Label: 262145 > 000. = MPLS Experimental Bits: 0 > ...1 = MPLS Bottom Of Label Stack: 1 > 1101 = MPLS TTL: 253 > Data (64 bytes) > > ff ff ff ff ff ff 00 50 79 66 68 01 08 06 00 01 ...Pyfh. > 0010 08 00 06 04 00 01 00 50 79 66 68 01 0a 48 01 42 ...Pyfh..H.B > 0020 ff ff ff ff ff ff 0a 48 01 43 00 00 00 00 00 00 ...H.C.. > 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Data: > 005079666801080600010800060400010050796668010a480142 > <80> > [Length: 64] > --- > 1 16:26:10.061638 ca:04:2c:7e:00:08 > 00:b5:df:d1:63:02, ethertype MPLS > unicast (0x8847), > length 82: MPLS (label 262145, exp 0, [S], ttl 253) > 00:50:79:66:68:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length > 64: Ethernet (len 6), > IPv4 (len 4), Request who-has 10.72.1.67 (ff:ff:ff:ff:ff:ff) tell 10.72.1.66, > length 50 > --- Already reported issue. Currently no fix. (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13306) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- On 31/03/2020 11:09, Francois-Xavier Le Bail via tcpdump-workers wrote: >> BTW how about DLT_LINUX_SLL2 as the default? What does it block? > To avoid breaking program that cannot use SLL2, could we have an API like > pcap_set_cooked_default_ssl2() or pcap_set_default_ssl2_on_any() and use it > in tcpdump? In fact, no need to change libpcap. Can be do in tcpdump code. See: https://github.com/the-tcpdump-group/tcpdump/pull/850 -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
