Builder libpcap-solaris11-i386 Build #141

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-libpcap-solaris11-i386' triggered this build

Steps and Logfiles:

1. git update ( 5 secs )
   1. stdio
2. shell './build_matrix.sh' ( 8 hrs, 33 mins, 33 secs )
   1. stdio
   2. config.log
3. trigger triggered trigger-tcpdump-solaris11-i386 ( 4 hrs, 45 mins, 19 secs )
   1. - no logs -
   2. tcpdump-solaris11-i386 #117

Build Properties:

Forced Build Properties:

Responsible Users:

1. Guy Harris

   gharrisohnoyoudont@sonic.net

Timing:

All Changes:

:

1. Change #260330

   Category	libpcap
   Changed by	Guy Harris <gharrisohnoyoudont@sonic.net>
   Changed at	Mon 09 Mar 2026 00:04:45
   Repository	https://git.tcpdump.org/libpcap
   Project	libpcap
   Branch	master
   Revision	d8194030872fab6337d2795449dd8031856807e1

   Comments

   Add a BPF_ flag to generate filter code for savefiles.
   DLT_NULL, DLT_LOOP, DLT_ENC, and DLT_PFLOG all have, in their link-layer
   headers, a field that contains an AF_ value that indicates the packet
   type, with AF_INET indicating an IPv4 packet and AF_INET6 indicating an
   IPv6 packet, and possibly with other values for other packet types.
   
   In the case of DLT_NULL and DLT_ENC, that's a multi-byte field in the
   byte order of the host on which the capture was done.
   
   For doing live captures, the code to generate is somewhat
   straightforward - you test for the host's values for AF_INET and
   AF_INET6, and, for DLT_NULL and DLT_ENC, you test for it in the host's
   byte order (which may involve some byte-swappping of the value for which
   we're testing, as the BPF machine's load instructions treat data in the
   packet as being in network byte order, i.e. treat them as being
   big-endian).
   
   For savefiles, however, we don't know the host on which the packets were
   originally captured, so we don't know what value was used for AF_INET6;
   different hosts that support those link-layer types have different
   values for AF_INET6. We also don't know the byte order of that host, as
   this file might, for example, be the result of processing a capture file
   on a host with a different byte order from the host on which the capture
   was originally done.
   
   Therefore, we have to generate more complicated filtering code, to
   handle captures from arbitrary hosts.
   
   The compiler used to test whether the pcap_t had a non-null rfile
   pointer, which would indicate that it's a savefile (it's a FILE * for
   that file).
   
   That makes it hard for filtertest to force generating code for a
   savefile, so that we can test what code is generated by the savefile
   code path.
   
   Now that we have a field in a pcap_t to specify other special code
   generation operations, we might as well add a flag to that for special
   handling of AF_ values; this allows a cleaner way for filtertest to
   request that, and makes the handling of code generation differences a
   bit cleaner and more unified.
   
   (Doing those tests in filtertest will be done in a later change.)

   Changed files

   • gencode.c
   • pcap-int.h
   • savefile.c