Support "direction" flags in capture files (such as the epb_flags field in pcapng) and dissect them as frame.* fields

This issue was migrated from bug 12329 in our old bug tracker.

Original bug information:

Reporter: lut…@‍ker…
Status: CONFIRMED
Product: Wireshark
Component: Capture file support (libwiretap)
OS: All
Platform: All
Version: unspecified

lut…@‍ker… said:

Build Information: wireshark 1.12.10 (Git Rev Unknown from unknown)

Copyright 1998-2016 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 3.18.7, with Cairo 1.14.2, with Pango 1.38.1, with GLib 2.46.2, with libpcap, with libz 1.2.8, with POSIX capabilities (Linux), with libnl 3, with SMI 0.4.8, with c-ares 1.10.0, without Lua, without Python, with GnuTLS 3.4.9, with Gcrypt 1.6.4, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 18 2015 15:46:29), without AirPcap.

Running on Linux 4.6.0-rc1-xps13+, with locale en_US.UTF-8, with libpcap version 1.7.4, with libz 1.2.8, GnuTLS 3.4.10, Gcrypt 1.6.4. Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz

Built using gcc 5.3.1 20151207 (Red Hat 5.3.1-2).

When I look at packet captures, it would be very, very useful if one of the columns in the main display showed the packet direction.  Simply distinguishing incoming from outgoing would be enough, but showing the full type (outgoing, incoming unicast, incoming broadcast, etc) would be nice, too.

Wireshark can provide this information for "cooked" captures, but cooked captures are rare and inconvenient, and the information is buried a couple levels deep in the dissector.

On Linux (at least all recent kernels, and I suspect it's true on all kernels ever), recvfrom and recvmsg on an AF_PACKET socket gives a sockaddr_ll.  That sockaddr_ll's sll_pkttype field is valid.  This works even in raw mode (I just tried it).

Please consider recording this information and displaying it in a column.

added enhancement libwiretap labels

Guy Harris said:

(In reply to luto from comment #0)  
> Wireshark can provide this information for "cooked" captures, but cooked  
> captures are rare and inconvenient, and the information is buried a couple  
> levels deep in the dissector.  
>  
> On Linux (at least all recent kernels, and I suspect it's true on all  
> kernels ever), recvfrom and recvmsg on an AF_PACKET socket gives a  
> sockaddr_ll.  That sockaddr_ll's sll_pkttype field is valid.  This works  
> even in raw mode (I just tried it).  
>  
> Please consider recording this information and displaying it in a column.  

We can only record the information if it's supplied to us, and currently libpcap/WinPcap doesn't supply it (some OSes, such as Linux, supply it to libpcap, but libpcap doesn't currently supply it to programs using it).

So this would require changes to libpcap in order to provide it for non-cooked captures.  libpcap/WinPcap will be changed in the future to support providing additional information, in a pcapng-style format.

This would also require changes to Wireshark, to get the direction information from a pcapng file (there's no place to put it in a pcap file).  This bug will be the bug to track those changes.

As for displaying it in a column, that will probably be done with custom columns - there would be a frame.{something} field to get the direction, which could be used as a custom column.  Technically, that would be a change to libwireshark, but there's no way to mark a bug as being for both libwiretap *and* libwireshark, so I'll just leave this as a libwiretap bug.

Guy Harris said:

Wireshark has supported displaying the flags option in the Enhanced Packet Block for a while now, so *this* bug is fixed.

If you capture on a Mac using Apple's tcpdump, you should get the direction information.  On other platforms, or on a Mac with Wireshark or anything else using the standard libpcap API rather than Apple's private APIs, no such luck.

At some point I want to give libpcap full-blown libpcap support, including getting EPBs when doing a live capture, complete with direction information if available on the platform.  That's a separate issue, and will involve separate changes to dumpcap to use the new APIs.  Once all that is done - including changes to tcpdump and dumpcap to support the new APIs - live captures with tcpdump, dumpcap, or any other program using the new APIs will have direction information if done on Linux (and, hopefully, Apple will pick up the new APIs and make them public, so that this will work for dumpcap captures on macOS as well).

Guy Harris said:

(In reply to Guy Harris from comment #2)  
> Wireshark has supported displaying the flags option in the Enhanced Packet  
> Block for a while now, so *this* bug is fixed.  

...in the sense that, if you have EPBs with a flags field, they will be shown.

However, captures done by dumpcap (including Wireshark and TShark captures) won't have those fields.  That requires more work, including considerable libpcap work.