Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message ---
Hi Guy,
> BTW, having just implemented SLL2 support in Wireshark, the layout of the
> header really doesn't work as well as I'd like with ARPHRD_NETLINK packets.
> I'd prefer something like
> struct header {
> uint16_t hatype;/* link-layer address type */
> uint8_t pkttype; /* packet type */
> uint8_t halen; /* link-layer address length */
> uint8_t addr[SLL_ADDRLEN]; /* link-layer address */
> int32_t if_index; /* 1-based interface index */
> uint16_t hatype_specific; /* dependent on sll3_hatype */
> uint16_t protocol; /* protocol */
> };
> because
> 1) It puts the protocol field *after* the hatype field, and right before the
> payload, so that, for packets with an hatype of ARPHRD_NETLINK, we can treat
> everything up to the if_index field as the cooked-mode header, and have the
> dissector for ARPHRD_NETLINK-over-SLL treat the hatype_specific and protocol
> fields as fields for *it* to dissect. For that ARPHRD_ type, the protocol is
> a Netlink protocol type, so it really should be analyzed by the code that
> understands Netlink messages.
> 2) It provides a field to handle various annoyances in the way that packets
> are provided to PF_PACKET sockets. In particular, Netlink messages are in
> the host byte order of the machine doing the capturing, so, for
> ARPHRD_NETLINK, we can have libpcap put the value 0x0123 in that field, in
> *host* byte order, so the code that processes the packets can just see
> whether that field's value is 0x0123 or 0x3210 and, based on that, determine
> whether the messages need to be byte-swapped. (Remember, somebody might
> capture Netlink traffic on a machine with one byte order but read the capture
> on a machine with the opposite byte order.)
> Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, or
> can we just change SLL2 at this point?
Thanks for the explanation. As I wrote at the ticket [1] I'd prefer to redefine
LINKTYPE_LINUX_SLL2/DLT_LINUX_SLL2. Having LINKTYPE_LINUX_SLL3/DLT_LINUX_SLL3,
when LINKTYPE_LINUX_SLL2/DLT_LINUX_SLL2 is not usable does not make much sense
to me. Hope it wasn't used much as it wasn't the default.
Kind regards,
Petr
[1] https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/3
--- 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 10/05/2020 10:04, Francois-Xavier Le Bail via tcpdump-workers wrote: > On 10/05/2020 00:37, Guy Harris via tcpdump-workers wrote: >> Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, >> or can we just change SLL2 at this point? > Just on the SLL2/SLL3 point: > > libpcap-1.9.1 is the first libpcap release to support SLL2, but > -No tcpdump currently release version supports SLL2. > -No Wireshark currently release version supports SLL2. > -As said in a previous message Snort, Scapy, Zeek don't support it. > > Therefore SLL2 use does not seem "sufficiently established" and we can just > change it. Not sure now ... We have to make tcpdump work with the already released libpcap 1.9.1 and current SLL2. If we update SLL2 and therefore tcpdump, can we make tcpdump works when linked to 1.9.1? -- 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 10/05/2020 00:37, Guy Harris via tcpdump-workers wrote: > Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, or > can we just change SLL2 at this point? Just on the SLL2/SLL3 point: libpcap-1.9.1 is the first libpcap release to support SLL2, but -No tcpdump currently release version supports SLL2. -No Wireshark currently release version supports SLL2. -As said in a previous message Snort, Scapy, Zeek don't support it. Therefore SLL2 use does not seem "sufficiently established" and we can just change it. -- 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 ---
BTW, having just implemented SLL2 support in Wireshark, the layout of the
header really doesn't work as well as I'd like with ARPHRD_NETLINK packets.
I'd prefer something like
struct header {
uint16_t hatype;/* link-layer address type */
uint8_t pkttype; /* packet type */
uint8_t halen; /* link-layer address length */
uint8_t addr[SLL_ADDRLEN]; /* link-layer address */
int32_t if_index; /* 1-based interface index */
uint16_t hatype_specific; /* dependent on sll3_hatype */
uint16_t protocol; /* protocol */
};
because
1) It puts the protocol field *after* the hatype field, and right before the
payload, so that, for packets with an hatype of ARPHRD_NETLINK, we can treat
everything up to the if_index field as the cooked-mode header, and have the
dissector for ARPHRD_NETLINK-over-SLL treat the hatype_specific and protocol
fields as fields for *it* to dissect. For that ARPHRD_ type, the protocol is a
Netlink protocol type, so it really should be analyzed by the code that
understands Netlink messages.
2) It provides a field to handle various annoyances in the way that packets are
provided to PF_PACKET sockets. In particular, Netlink messages are in the host
byte order of the machine doing the capturing, so, for ARPHRD_NETLINK, we can
have libpcap put the value 0x0123 in that field, in *host* byte order, so the
code that processes the packets can just see whether that field's value is
0x0123 or 0x3210 and, based on that, determine whether the messages need to be
byte-swapped. (Remember, somebody might capture Netlink traffic on a machine
with one byte order but read the capture on a machine with the opposite byte
order.)
Is SLL2 sufficiently established that we'd have to introduce an SLL3 type, or
can we just change SLL2 at this point?--- 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 --- Since there's interest in SLL2 here, I'd like to raise the visibility of my libpcap pull request for filtering on ifindex: https://github.com/the-tcpdump-group/libpcap/pull/829 It filters on both live "any" captures (SLL or SLL2) and reading from a saved SLL2 pcap. Bill --- 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] 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
Re: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- 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? -- 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 --- 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? Kind regards, Petr --- 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 --- Hi Francois, > > The "-y" flag to tcpdump allows you to specify capturing with > > DLT_LINUX_SLL2. > Should DLT_LINUX_SLL2 be now the default when tcpdump is built with a libpcap > that support it ? I'd be glad if it was so, but not sure if first wireshark needs to support it. BTW man pages (pcap.3pcap.in, pcap_datalink.3pcap.in, pcap_loop.3pcap and pcap_next_ex.3pcap) mention only DLT_LINUX_SLL. Kind regards, Petr --- 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 --- Hi Bill, > The "-y" flag to tcpdump allows you to specify capturing with > DLT_LINUX_SLL2. Thanks a lot! Kind regards, Petr --- 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 13/03/2020 12:35, Bill Fenner via tcpdump-workers wrote: > > The "-y" flag to tcpdump allows you to specify capturing with > DLT_LINUX_SLL2. Should DLT_LINUX_SLL2 be now the default when tcpdump is built with a libpcap that support it ? -- 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 --- The "-y" flag to tcpdump allows you to specify capturing with DLT_LINUX_SLL2. //tmp @fenner-t493.sjc% tcpdump -i any -y linux_sll2 udp port 53 tcpdump: data link type linux_sll2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes 04:34:16.440349 ifindex 2 (e-a4c-281e9814) Out 8e:18:55:e1:02:4b (oui Unknown) ethertype IPv4 (0x0800), length 81: me.4 > dnsserver.domain: 53929+ A? www.tcpdump.org. (33) Bill On Wed, Mar 11, 2020 at 2:49 PM Petr Vorel via tcpdump-workers < tcpdump-workers@lists.tcpdump.org> wrote: > > > > -- Forwarded message -- > From: Petr Vorel > To: Guy Harris > Cc: tcpdump-workers@lists.tcpdump.org, Denis Ovsienko > > Bcc: > Date: Wed, 11 Mar 2020 19:49:18 +0100 > Subject: Compile libpcap with DLT_LINUX_SLL2 > Hi Guy, > > some time ago we did together DLT_LINUX_SLL2 support for libpcap. > I don't remember the details, but IMHO it was enabled by default. > When now I compile libpcap and tcpdump, it's still using DLT_LINUX_SLL: > > tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), ... > > What do I do wrong? > > Kind regards, > Petr > > > > -- Forwarded message -- > From: Petr Vorel via tcpdump-workers > To: Guy Harris > Cc: tcpdump-workers@lists.tcpdump.org > Bcc: > Date: Wed, 11 Mar 2020 14:48:19 -0400 (EDT) > Subject: [tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2 > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Compile libpcap with DLT_LINUX_SLL2
--- Begin Message --- Hi Guy, some time ago we did together DLT_LINUX_SLL2 support for libpcap. I don't remember the details, but IMHO it was enabled by default. When now I compile libpcap and tcpdump, it's still using DLT_LINUX_SLL: tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), ... What do I do wrong? Kind regards, Petr --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
