libpcap
libpcap copied to clipboard
the-tcpdump-group
Display/filter on packet direction and interface name
Converted from SourceForge issue 2850109, submitted by leonerd
When capturing from a single interface, libpcap only allows the EN10MB link type, which contains only the ethernet frame, with no context such as would provide packet direction. This makes it impossible to dump a single interface and know the direction.
When capturing from "-i any", libpcap on Linux provides LINUX_SLL, which seems to throw away such useful information as ifindex, making it impossible to know which of the many interfaces the packet was found on.
Please therefore provide some way to have all of this; if by no other mechanism, lets have LINUX_SLL2 which is a complete copy of the entire struct sockaddr_ll, which will therefore have the sll_pkttype (for direction) and sll_ifindex (for interface index) fields. Allow any capture on Linux, of a single interface or all, to switch to this frame type.
This would allow us to make tcpdump incantations such as the following, which right now are impossible:
Capture packets pertaining to the locally running SSH server, ignoring any locally running SSH clients
tcpdump inbound tcp dest port 22 or outbound tcp source port 22
I am a firewalling bridge, capture packets flowing in one direction only, to see what is being dropped
tcpdump -i any inbound ifname "eth0" or outbound ifname "eth1"
Using this newfound information, it would then be possible for tcpdump's packet output to display it; I might suggest something like:
tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:25:08.727472 Tx IP 192.168.2.221 > 192.168.2.1: ICMP echo request, id 62524, seq 3, length 64 17:25:08.727642 Rx IP 192.168.2.1 > 192.168.2.221: ICMP echo reply, id 62524, seq 3, length 64
tcpdump -n -i any
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 17:26:42.944458 Rx(eth0) ARP, Request who-has 192.168.2.133 tell 192.168.2.135, length 46 17:26:43.105021 Rx(eth0) ARP, Request who-has 192.168.0.251 tell 192.168.0.1, length 46
Submitted by leonerd
Just to make clear; I am aware the tcpdump output would be a separate bug on the separate project, but it needs data from libpcap first, so I thought I'd start here. Also the filtering is done here. Once libpcap can provide it I'll then go and report a companion bug on tcpdump - or more likely just write the code myself and supply a patch as it's likely to be small and easy.
If nobody else wants to actually do this I'm quite happy to have a go implementing it, if someone can point me in a rough direction and suggest how likely it is my work would actually be accepted.
I would suggest asking on tcpdump-workers mailing list if that is doable by some other mean. If adding a new DLT is the only way, it would make sense to check what extra (compared to SLL) information SLL2 can have besides ifindex, ifname and direction (to save time defining SSL3 for the next kind of metadata). Once decided on SLL2 encoding, please post it to tcpdump-workers and request a DLT number for it. Once implemented, please place a pull request for a review.
Is there actually any progress on this? This has been sitting around well over a year now - some of my workaround code where I reimplement tcpdump to get this feature is over 4 years old.
Are you willing to implement this? If yes, could you post a specification for DLT_LINUX_SLL2 like http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html (in the-tcpdump-group/tcpdump-htdocs repository) and a request for a new DLT to the tcpdump-workers mailing list?
I'm certainly willing to have a go, if there's a chance it'll actually get accepted and go somewhere useful yes.
@infrastation So how do I do this - do I copy/edit the actual .html file, headers and all?
OK; first attempt at: https://github.com/leonerd/tcpdump-htdocs/blob/master/linktypes/LINKTYPE_LINUX_SLL2.html
If you think that looks passable I'll send a pull req.
Also, I've subscribed to the tcpdump-workers mailing list and tried sending a few posts, but none of them seem ever to get through. I wonder if I'm being blackholed there :/
Yahoo is known not to work, other mails should be OK. @mcr, could you check? Thank you!
@mcr, @infrastation It's not Yahoo, it's my own mail server at home. leonerd at leonerd dot org dot uk I do have an IPv6 address, not sure if that's the reason. I'm subscribed to the list, and I do receive posts other people make.
I see: leonerd at leonerd dot org dot uk subscribed. I see nothing in the spam filter. Try sending again, watch your logs, and email mcr at sandelman dot ca directly the log results.
@mcr - any luck yet? I wrote that mail about a week ago, haven't heard anything back yet. A possibility that my debug mail too got lost? If so, find a copy here: http://pastie.org/private/kj6l9adjncruqqezzf66a
Paul has replied to my post to tcpdump-workers (to me, CC to tcpdump-workers) and the message didn't make it to tcpdump-workers. In my personal email the reply landed in the spam folder but that's not unusual. The Date header of the message is "Tue, 13 Jan 2015 15:37:09 +0000".
ping. If someone is willing to put the technical work to implement this, it seems like a pitty that this gets black-holed because technical issues with the mailing list no?
The mailing list is fine. AFAIR the issue has been discussed on the list and the best solution agreed upon. It is the actual working code that is still missing.
I believe the SLL2 format is defined in documentation now, yes.
(edit) in fact yes, it's right here https://github.com/the-tcpdump-group/tcpdump-htdocs/blob/master/linktypes/LINKTYPE_LINUX_SLL2.html
"Created: 2009-09-03" (originally on SF) -- it's been quite a while. Paul Evans had stated the problem and discussed the solution, Guy Harris has recently developed the code for it. Is it OK to close this long-standing request as resolved?
The original request says: "Allow any capture on Linux, of a single interface or all, to switch to this frame type."
The "all" part now works almost as requested (-e makes the direction visible for SLL2). Does the current interface to the Linux kernel allow to implement the "single interface" part (I vaguely remember there was some difference between the twocases)?
Do all of my suggested filtering types work?
-f "ifname eth0"
-f "ifindex 2"
-f "inbound" or "outbound"
The aliases for more complex filters
-f "tcp local port 22" => -f "inbound tcp dest port 22 or outbound tcp source port 22"
-f "tcp remote port 22" => similar
These two are useful for watching (e.g. in this case) ssh servers, or clients, running on the local machine without falsely capturing the other.
Does the ifindex/ifname and packet type/direction appear in the output?
You are right, this feature request scope is bigger than the current initial implementation, so let's keep it open. Would you like to contribute some code?
In the current implementation of SLL2 the interface index is always present in the output and interface name is present if it can be translated from the index. The packet direction is present if -e flag has been given (as with SLL1). Sample output:
$ ./tcpdump/tcpdump -n -r SLL2-20180719.pcap
reading from file SLL2-20180719.pcap, link-type LINUX_SLL2 (Linux cooked v2)
Warning: interface names might be incorrect
07:18:02.887663 ifindex 2 (eth0) IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:07.277860 ifindex 2 (eth0) IP 37.1.196.25.50499 > 176.58.103.64.32792: Flags [S], seq 3962260604, win 1024, length 0
07:18:07.277900 ifindex 2 (eth0) IP 176.58.103.64.32792 > 37.1.196.25.50499: Flags [R.], seq 0, ack 3962260605, win 0, length 0
07:18:07.502161 ifindex 2 (eth0) IP 37.1.196.25.50499 > 176.58.103.64.32792: Flags [R], seq 3962260605, win 1200, length 0
07:18:07.893707 ifindex 2 (eth0) IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:12.905617 ifindex 2 (eth0) IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:17.917483 ifindex 2 (eth0) IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:22.935245 ifindex 2 (eth0) IP6 fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:23.655183 ifindex 2 (eth0) IP 193.29.13.157.49674 > 176.58.103.64.3344: Flags [S], seq 3991579437, win 1024, length 0
07:18:23.655238 ifindex 2 (eth0) IP 176.58.103.64.3344 > 193.29.13.157.49674: Flags [R.], seq 0, ack 3991579438, win 0, length 0
$ ./tcpdump/tcpdump -e -n -r SLL2-20180719.pcap
reading from file SLL2-20180719.pcap, link-type LINUX_SLL2 (Linux cooked v2)
Warning: interface names might be incorrect
07:18:02.887663 ifindex 2 (eth0) M 00:05:73:a0:0f:ff ethertype IPv6 (0x86dd), length 124: fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:07.277860 ifindex 2 (eth0) In 84:78:ac:5a:1a:41 ethertype IPv4 (0x0800), length 66: 37.1.196.25.50499 > 176.58.103.64.32792: Flags [S], seq 3962260604, win 1024, length 0
07:18:07.277900 ifindex 2 (eth0) Out f2:3c:91:36:f7:be ethertype IPv4 (0x0800), length 60: 176.58.103.64.32792 > 37.1.196.25.50499: Flags [R.], seq 0, ack 3962260605, win 0, length 0
07:18:07.502161 ifindex 2 (eth0) In 84:78:ac:5a:1a:41 ethertype IPv4 (0x0800), length 66: 37.1.196.25.50499 > 176.58.103.64.32792: Flags [R], seq 3962260605, win 1200, length 0
07:18:07.893707 ifindex 2 (eth0) M 00:05:73:a0:0f:ff ethertype IPv6 (0x86dd), length 124: fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:12.905617 ifindex 2 (eth0) M 00:05:73:a0:0f:ff ethertype IPv6 (0x86dd), length 124: fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:17.917483 ifindex 2 (eth0) M 00:05:73:a0:0f:ff ethertype IPv6 (0x86dd), length 124: fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:22.935245 ifindex 2 (eth0) M 00:05:73:a0:0f:ff ethertype IPv6 (0x86dd), length 124: fe80::1 > ff02::1: ICMP6, router advertisement, length 64
07:18:23.655183 ifindex 2 (eth0) In 84:78:ac:5a:1a:41 ethertype IPv4 (0x0800), length 66: 193.29.13.157.49674 > 176.58.103.64.3344: Flags [S], seq 3991579437, win 1024, length 0
07:18:23.655238 ifindex 2 (eth0) Out f2:3c:91:36:f7:be ethertype IPv4 (0x0800), length 60: 176.58.103.64.3344 > 193.29.13.157.49674: Flags [R.], seq 0, ack 3991579438, win 0, length 0
DLT_LINUX_SLL2 was implemented in 8cff296dc7c321c76933359d586dbde5b580ce8c + there has been some fixes and enhancements: a1bc985bb6aac4522b6bea725a2ad7e65d6cea0f e06e9b39da8d38553028af204cb691cf794325ed 014e6a0fca0a25ba74242ba76e27afaa5799e0b7.
Also DLT_LINUX_SLL2 has been set as the default for tcpdump in https://github.com/the-tcpdump-group/tcpdump/commit/8d3c2ed39e1b365da42c3aa5d2c5d6a6a5796bac (https://github.com/the-tcpdump-group/tcpdump/pull/850).
Thus I guess we can close this. Or is there anything to be done?
And after releasing libpcap 1.10 DLT_LINUX_SLL2 could be implemented in Wireshark, right?
Also, an "ifindex N" filter was implemented in 014e6a0. I got foiled in implementing "ifname foo0" because of the existing implementation's tight linkage with PF - (maybe I should have just picked a different keyword) - but obviously that translates to an ifindex comparison so only works on a live capture (or a system with exactly the same ifindex mapping as the savefile - which even the system on which it was captured might not be).
An idea... can this information be decoupled from LINUX_SLL and LINUX_SLL2? Also we can take advantage of PCAPng metadata to store it. It has fields specifically for this purpose: Interface name - Interface Description Block -> options -> if_name Direction - Enhanced Packet Block -> epb_flags -> Bits 0-1
