FILES
-----
CHANGES - description of differences between releases
-ChmodBPF/* - Mac OS X startup item to set ownership and permissions
+ChmodBPF/* - macOS startup item to set ownership and permissions
on /dev/bpf*
CMakeLists.txt - CMake file
CONTRIBUTING - guidelines for contributing
README.dag - notes on using libpcap to capture on Endace DAG devices
README.hpux - notes on using libpcap on HP-UX
README.linux - notes on using libpcap on Linux
-README.macosx - notes on using libpcap on Mac OS X
+README.macos - notes on using libpcap on macOS
README.septel - notes on using libpcap to capture on Intel/Septel devices
README.sita - notes on using libpcap to capture on SITA devices
README.tru64 - notes on using libpcap on Digital/Tru64 UNIX
README.dag \
README.hpux \
README.linux \
- README.macosx \
+ README.macos \
README.septel \
README.sita \
README.tru64 \
#
# The following rule succeeds, but the result is untested.
#
-# In Mac OS X, the libpcap dylib has the name "libpcap.A.dylib", with
-# its full path as the install_name, and with the compatibility and
-# current version both set to 1. The compatibility version is set to
-# 1 so that programs built with a newer version of the library will run
-# against older versions; multi-platform software probably will fail if
-# it uses APIs added in the newer version, but Mac OS X-specific software
-# will use weak linking and check at run time whether those APIs are
-# available.
+# In macOS, the libpcap dylib has the name "libpcap.A.dylib", with its
+# full path as the install_name, and with the compatibility and current
+# version both set to 1. The compatibility version is set to 1 so that
+# programs built with a newer version of the library will run against
+# older versions if they don't use APIs available in the newer version
+# but not in the older version.
#
# We also use "A" as the major version, and 1 as the compatibility version,
# but set the current version to the value in VERSION, with any non-numeric
with the underlying kernel subsystem, but this is not yet implemented.
BPF is standard in 4.4BSD, BSD/OS, NetBSD, FreeBSD, OpenBSD, DragonFly
-BSD, and Mac OS X; an older, modified and undocumented version is
-standard in AIX. {DEC OSF/1, Digital UNIX, Tru64 UNIX} uses the
-packetfilter interface but has been extended to accept BPF filters
-(which libpcap utilizes). Also, you can add BPF filter support to
-Ultrix using the kernel source and/or object patches available in:
+BSD, and macOS; an older, modified and undocumented version is standard
+in AIX. {DEC OSF/1, Digital UNIX, Tru64 UNIX} uses the packetfilter
+interface but has been extended to accept BPF filters (which libpcap
+utilizes). Also, you can add BPF filter support to Ultrix using the
+kernel source and/or object patches available in:
https://www.tcpdump.org/other/bpfext42.tar.Z
-As with other systems using BPF, Mac OS X allows users with read access
-to the BPF devices to capture packets with libpcap and allows users with
+As with other systems using BPF, macOS allows users with read access to
+the BPF devices to capture packets with libpcap and allows users with
write access to the BPF devices to send packets with libpcap.
On some systems that use BPF, the BPF devices live on the root file
devices to give users other than root permission to read or write those
devices.
-On Mac OS X, the BPF devices live on devfs, but the OS X version of
-devfs is based on an older (non-default) FreeBSD devfs, and that version
-of devfs cannot be configured to set the permissions and/or ownership of
+On macOS, the BPF devices live on devfs, but the macOS version of devfs
+is based on an older (non-default) FreeBSD devfs, and that version of
+devfs cannot be configured to set the permissions and/or ownership of
those devices.
Therefore, we supply:
- a "startup item" for older versions of Mac OS X;
+ a "startup item" for older versions of macOS;
- a launchd daemon for Tiger and later versions of Mac OS X;
+ a launchd daemon for Tiger and later versions of macOS;
Both of them will change the ownership of the BPF devices so that the
"admin" group owns them, and will change the permission of the BPF
# On platforms where we build a shared library:
#
# add options to generate position-independent code,
- # if necessary (it's the default in AIX and Darwin/OS X);
+ # if necessary (it's the default in AIX and Darwin/macOS);
#
# define option to set the soname of the shared library,
# if the OS supports that;
# where we build a shared library:
#
# add options to generate position-independent code,
- # if necessary (it's the default in Darwin/OS X);
+ # if necessary (it's the default in Darwin/macOS);
#
# if we generate ".so" shared libraries, define the
# appropriate options for building the shared library;
#! /bin/sh
#
-# Unfortunately, Mac OS X's devfs is based on the old FreeBSD
+# Unfortunately, macOS's devfs is based on the old FreeBSD
# one, not the current one, so there's no way to configure it
# to create BPF devices with particular owners or groups.
# This startup item will make it owned by the admin group,
# On platforms where we build a shared library:
#
# add options to generate position-independent code,
- # if necessary (it's the default in AIX and Darwin/OS X);
+ # if necessary (it's the default in AIX and Darwin/macOS);
#
# define option to set the soname of the shared library,
# if the OS supports that;
# where we build a shared library:
#
# add options to generate position-independent code,
- # if necessary (it's the default in Darwin/OS X);
+ # if necessary (it's the default in Darwin/macOS);
#
# if we generate ".so" shared libraries, define the
# appropriate options for building the shared library;
/*
* Note that, on some platforms, ifa_broadaddr and
* ifa_dstaddr could be the same field (true on at
- * least some versions of *BSD and OS X), so we
+ * least some versions of *BSD and macOS), so we
* can't just check whether the broadcast address
* is null and add it if so and check whether the
* destination address is null and add it if so.
*/
#define BSD_AFNUM_INET6_BSD 24 /* NetBSD, OpenBSD, BSD/OS, Npcap */
#define BSD_AFNUM_INET6_FREEBSD 28 /* FreeBSD */
-#define BSD_AFNUM_INET6_DARWIN 30 /* OS X, iOS, other Darwin-based OSes */
+#define BSD_AFNUM_INET6_DARWIN 30 /* macOS, iOS, other Darwin-based OSes */
/*
* Generate code to match a particular packet type by matching the
* <net/bpf.h> defines ioctls, but doesn't include <sys/ioccom.h>.
*
* We include <sys/ioctl.h> as it might be necessary to declare ioctl();
- * at least on *BSD and Mac OS X, it also defines various SIOC ioctls -
+ * at least on *BSD and macOS, it also defines various SIOC ioctls -
* we could include <sys/sockio.h>, but if we're already including
* <sys/ioctl.h>, which includes <sys/sockio.h> on those platforms,
* there's not much point in doing so.
#endif
/*
- * On OS X, we don't even get any of the 802.11-plus-radio-header DLT_'s
- * defined, even though some of them are used by various Airport drivers.
+ * In some versions of macOS, we might not even get any of the
+ * 802.11-plus-radio-header DLT_'s defined, even though some
+ * of them are used by various Airport drivers in those versions.
*/
#ifndef DLT_PRISM_HEADER
#define DLT_PRISM_HEADER 119
#endif
/*
- * The joys of monitor mode on OS X.
+ * The joys of monitor mode on Mac OS X/OS X/macOS.
*
* Prior to 10.4, it's not supported at all.
*
#ifdef __APPLE__
if (ret == -1 && errno == EAFNOSUPPORT) {
/*
- * In Mac OS X, there's a bug wherein setting the
- * BIOCSHDRCMPLT flag causes writes to fail; see,
- * for example:
+ * In some versions of macOS, there's a bug wherein setting
+ * the BIOCSHDRCMPLT flag causes writes to fail; see, for
+ * example:
*
* http://cerberus.sourcefire.com/~jeff/archives/patches/macosx/BIOCSHDRCMPLT-10.3.3.patch
*
- * So, if, on OS X, we get EAFNOSUPPORT from the write, we
+ * So, if, on macOS, we get EAFNOSUPPORT from the write, we
* assume it's due to that bug, and turn off that flag
* and try again. If we succeed, it either means that
* somebody applied the fix from that URL, or other patches
* http://cerberus.sourcefire.com/~jeff/archives/patches/macosx/
*
* and are running a Darwin kernel with those fixes, or
- * that Apple fixed the problem in some OS X release.
+ * that Apple fixed the problem in some macOS release.
*/
u_int spoof_eth_src = 0;
/*
* pfsync output; DLT_PFSYNC is 18, which collides with DLT_CIP in
- * SuSE 6.3, on OpenBSD, NetBSD, DragonFly BSD, and Mac OS X, and
+ * SuSE 6.3, on OpenBSD, NetBSD, DragonFly BSD, and macOS, and
* is 121, which collides with DLT_HHDLC, in FreeBSD. We pick a
* shiny new link-layer header type value that doesn't collide with
* anything, in the hopes that future pfsync savefiles, if any,
* So I'll just give them one; hopefully this will show up in a
* libpcap release in time for them to get this into 10.10 Big Sur
* or whatever Mavericks' successor is called. LINKTYPE_PKTAP
- * will be 258 *even on OS X*; that is *intentional*, so that
+ * will be 258 *even on macOS*; that is *intentional*, so that
* PKTAP files look the same on *all* OSes (different OSes can have
* different numerical values for a given DLT_, but *MUST NOT* have
* different values for what goes in a file, as files can be moved
promiscuous-mode or copy-all-mode operation, or both modes of
operation, be enabled on that interface.
.TP
-.B Under BSD (this includes Mac OS X):
+.B Under BSD (this includes macOS):
You must have read access to
.I /dev/bpf*
on systems that don't have a cloning BPF device, or to
.I /dev/bpf
on systems that do.
-On BSDs with a devfs (this includes Mac OS X), this might involve more
+On BSDs with a devfs (this includes macOS), this might involve more
than just having somebody with super-user access setting the ownership
or permissions on the BPF devices - it might involve configuring devfs
to set the ownership or permissions every time the system is booted,
* description available, it still might be nice to get some description
* string based on the device type or something such as that.
*
- * In OS X, the System Configuration framework can apparently return
+ * In macOS, the System Configuration framework can apparently return
* names in 10.4 and later.
*
* It also appears that freedesktop.org's HAL offers an "info.product"
/*
* 18 is used for DLT_PFSYNC in OpenBSD, NetBSD, DragonFly BSD and
- * Mac OS X; don't use it for anything else. (FreeBSD uses 121,
- * which collides with DLT_HHDLC, even though it doesn't use 18
- * for anything and doesn't appear to have ever used it for anything.)
+ * macOS; don't use it for anything else. (FreeBSD uses 121, which
+ * collides with DLT_HHDLC, even though it doesn't use 18 for
+ * anything and doesn't appear to have ever used it for anything.)
*
* We define it as 18 on those platforms; it is, unfortunately, used
* for DLT_CIP in Suse 6.3, so we don't define it as DLT_PFSYNC
*
* FreeBSD's libpcap won't map a link-layer header type of 18 - i.e.,
* DLT_PFSYNC files from OpenBSD and possibly older versions of NetBSD,
- * DragonFly BSD, and OS X - to DLT_PFSYNC, so code built with FreeBSD's
+ * DragonFly BSD, and macOS - to DLT_PFSYNC, so code built with FreeBSD's
* libpcap won't treat those files as DLT_PFSYNC files.
*
* Other libpcaps won't map a link-layer header type of 121 to DLT_PFSYNC;
* So I'll just give them one; hopefully this will show up in a
* libpcap release in time for them to get this into 10.10 Big Sur
* or whatever Mavericks' successor is called. LINKTYPE_PKTAP
- * will be 258 *even on OS X*; that is *intentional*, so that
+ * will be 258 *even on macOS*; that is *intentional*, so that
* PKTAP files look the same on *all* OSes (different OSes can have
* different numerical values for a given DLT_, but *MUST NOT* have
* different values for what goes in a file, as files can be moved
* and that will continue to be DLT_USER2 on Darwin-based OSes. That way,
* binary compatibility with Mavericks is preserved for programs using
* this version of libpcap. This does mean that if you were using
- * DLT_USER2 for some capture device on OS X, you can't do so with
+ * DLT_USER2 for some capture device on macOS, you can't do so with
* this version of libpcap, just as you can't with Apple's libpcap -
- * on OS X, they define DLT_PKTAP to be DLT_USER2, so programs won't
+ * on macOS, they define DLT_PKTAP to be DLT_USER2, so programs won't
* be able to distinguish between PKTAP and whatever you were using
* DLT_USER2 for.
*
*
* https://bugs.kde.org/show_bug.cgi?id=318203
*
- * and valgrind bug 312989 for OS X:
+ * and valgrind bug 312989 for macOS:
*
* https://bugs.kde.org/show_bug.cgi?id=312989
*
* The fixes for both of those are checked into the official valgrind
* repository.
*
- * The unofficial FreeBSD port has similar issues to the official OS X
+ * The unofficial FreeBSD port has similar issues to the official macOS
* port, for similar reasons.
*/
#ifndef lint
projects / libpcap / commitdiff
