See https://www.usenix.org/legacy/events/bsdcon02/full_papers/lidl/lidl_html/index.html for some information on that; we probably won't be implementing those extensions, but we might want to avoid using the encodings used by them.
At minimum, we'd like to keep track of new instructions added, so that others don't use the same encoding for different operations. Ideally, we'd like to update our implementation to support the new instructions and encourage other implementations to add them as well. Also remove the "from Linux" note on BPF_MOD and BPF_XOR, as the Linux kernel BPF implementation isn't the only one that has them now, given that we have them.
Same opcodes as on Linux. We support them in BPF filters, but warn, in the man page, that using them on anything other than Linux 3.7 or later will cause the filter to run in userland and thus require more resources and perhaps cause more packets to be dropped. (The filter will presumably be rejected by the kernel-mode code if it doesn't support BPF_MOD or BPF_XOR, and libpcap will fall back on running the filter in userland.)
This is a new link-layer header type for the Bluetooth Linux Monitor in the BlueZ Bluetooth stack.
That means that, when reading a LINKTYPE_NFLOG file, the type and length values are in the byte order of the host *reading* the file, rather than the host that *wrote* the file, just as they're in the byte order of the host capturing the traffic if you're doing a live capture of NFLOG messages. That way, when reading a LINKTYPE_NFLOG file and writing another one from those packets, the type and length in the output file will be in the byte order of the host writing the file, rather than the byte order of the host that wrote the input file. Export the nflog.h file containing the declarations and definitions we need, for use by tcpdump and other programs reading LINKTYPE_NFLOG files. Put the bulk of the byte-swapping code into a common routine, for use by pcap and pcap-ng readers, while we're at it.
With Linux 3.11, we have the possibility to debug local netlink traffic  i.e. the workflow looks like this: Setup: modprobe nlmon ip link add type nlmon ip link set nlmon0 up Capture: tcpdump -i nlmon0 ... Teardown: ip link set nlmon0 down ip link del dev nlmon0 rmmod nlmon For pcap interoperability, introduce a common link type for netlink captures.
Do time stamp precisions the way we do time stamp types - if a module supports more than one time stamp precision, have it attach a table of time stamp precisions to the pcap_t, and have the code to set the time stamp check that list. Check for the two #ifdefs in pcap-linux.c to see whether it supports nanosecond time stamps - and don't use the ioctl or the socket option for those #ifdefs if they're not defined. This means we don't need to check for it in the configure script. Also, have both the time stamp type-setting and precision-setting routines allow the default value (PCAP_TSTAMP_NONE/PCAP_TSTAMP_PRECISION_MICRO) if no list is supplied. Make "can't set the precision" an error; not being able to set the time stamp *type* doesn't mean your code won't work at all, it just means the time stamps won't be as accurate as you'd like, but not being able to set the time stamp *precision* means you'll be getting seconds/microseconds, and your code may have to cope with that.
As with the open_offline routines, so with pcap_open_dead(); instead of a nanosecond-resolution version, have a pcap_open_dead_with_tstamp_precision() routine that takes a PCAP_TSTAMP_PRECISION_ value, and make pcap_open_dead() a wrapper that requests microsecond resolution. Declare it in pcap/pcap.h while we're at it.
For opening savefiles, instead of having separate open_offline and open_offline_nsectime routines, have open_offline_with_tstamp_precision routies that take an additional PCAP_TSTAMP_PRECISION_xxx argument, and make the open_offline routines wrappers around them requesting microsecond precision. Also, the timestamp precisions are a separate "namespace" from the timestamp types, so give them their own numerical value set, starting at 0 for microsecond precision. For pcap files, figure out up front whether we pass the time stamps through, scale them up, or scale them down, and save that with the private data and just use it when reading the capture file; that's less work than determining that for every packet.
In most cases, DLT_ values and LINKTYPE_ values are the same, but, in some cases, DLT_ values are platform-dependent, but LINKTYPE_ values aren't, so that a savefile can be read on platforms other than the one on which it was created.
They have the same numerical value, as with all newly-added link-layer header types.
Two new functions are introduced, pcap_set_tstamp_precision() and pcap_get_tstamp_precision(). Those functions allow one to specify desired timestamps precision for captured packets. By default application will obtain timestamps in microseconds.
…itories. We've created a the-tcpdump-group organization on GitHub, and created repositories for libpcap and tcpdump, owned by them. Those are now the "official" GitHub locations for repositories from which to clone or against which to file issues/pull requests.