{
    "mode": "man",
    "parameter": "pcap-filter",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/pcap-filter/7/json",
    "generated": "2026-05-30T06:06:09Z",
    "sections": {
        "NAME": {
            "content": "pcap-filter - packet filter syntax\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "pcapcompile()  is used to compile a string into a filter program.  The resulting filter pro‐\ngram can then be applied to some stream of packets to determine which packets  will  be  sup‐\nplied to pcaploop(3PCAP), pcapdispatch(3PCAP), pcapnext(3PCAP), or pcapnextex(3PCAP).\n\nThe  filter  expression consists of one or more primitives.  Primitives usually consist of an\nid (name or number) preceded by one or more qualifiers.  There are three different  kinds  of\nqualifier:\n\ntype   type  qualifiers  say  what  kind  of thing the id name or number refers to.  Possible\ntypes are host, net, port and portrange.  E.g., `host foo', `net  128.3',  `port  20',\n`portrange 6000-6008'.  If there is no type qualifier, host is assumed.\n\ndir    dir  qualifiers  specify  a particular transfer direction to and/or from id.  Possible\ndirections are src, dst, src or dst, src and dst, ra, ta,  addr1,  addr2,  addr3,  and\naddr4.   E.g., `src foo', `dst net 128.3', `src or dst port ftp-data'.  If there is no\ndir qualifier, `src or dst' is assumed.  The ra, ta, addr1, addr2,  addr3,  and  addr4\nqualifiers are only valid for IEEE 802.11 Wireless LAN link layers.\n\nproto  proto  qualifiers  restrict  the match to a particular protocol.  Possible protos are:\nether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp  and  udp.   E.g.,  `ether  src\nfoo',  `arp  net  128.3',  `tcp  port  21',  `udp  portrange  7000-7009',  `wlan addr2\n0:2:3:4:5:6'.  If there is no proto qualifier, all protocols consistent with the  type\nare  assumed.   E.g., `src foo' means `(ip or arp or rarp) src foo' (except the latter\nis not legal syntax), `net bar' means `(ip or arp or rarp)  net  bar'  and  `port  53'\nmeans `(tcp or udp) port 53'.\n\n[fddi  is  actually  an  alias for ether; the parser treats them identically as meaning ``the\ndata link level used on the specified network interface''.  FDDI  headers  contain  Ethernet-\nlike  source  and destination addresses, and often contain Ethernet-like packet types, so you\ncan filter on these FDDI fields just as with the analogous  Ethernet  fields.   FDDI  headers\nalso contain other fields, but you cannot name them explicitly in a filter expression.\n\nSimilarly,  tr and wlan are aliases for ether; the previous paragraph's statements about FDDI\nheaders also apply to Token Ring and 802.11 wireless LAN headers.  For  802.11  headers,  the\ndestination  address  is  the DA field and the source address is the SA field; the BSSID, RA,\nand TA fields aren't tested.]\n\nIn addition to the above, there are some special `primitive' keywords that don't  follow  the\npattern:  gateway, broadcast, less, greater and arithmetic expressions.  All of these are de‐\nscribed below.\n\nMore complex filter expressions are built up by using the words and, or and not  (or  equiva‐\nlently: `&&', `||' and `!' respectively) to combine primitives.  E.g., `host foo and not port\nftp and not port ftp-data'.  To save typing, identical qualifier lists can be omitted.  E.g.,\n`tcp  dst port ftp or ftp-data or domain' is exactly the same as `tcp dst port ftp or tcp dst\nport ftp-data or tcp dst port domain'.\n\nAllowable primitives are:\n\ndst host host\nTrue if the IPv4/v6 destination field of the packet is host, which may  be  either  an\naddress or a name.\n\nsrc host host\nTrue if the IPv4/v6 source field of the packet is host.\n\nhost host\nTrue if either the IPv4/v6 source or destination of the packet is host.\n\nAny  of  the above host expressions can be prepended with the keywords, ip, arp, rarp,\nor ip6 as in:\nip host host\nwhich is equivalent to:\nether proto \\ip and host host\nIf host is a name with multiple IPv4 addresses, each address will  be  checked  for  a\nmatch.\n\nether dst ehost\nTrue  if  the  Ethernet destination address is ehost.  Ehost may be either a name from\n/etc/ethers  or  a  numerical   MAC   address   of   the   form   \"xx:xx:xx:xx:xx:xx\",\n\"xx.xx.xx.xx.xx.xx\", \"xx-xx-xx-xx-xx-xx\", \"xxxx.xxxx.xxxx\", \"xxxxxxxxxxxx\", or various\nmixes of ':', '.', and '-', where each \"x\" is a hex digit (0-9, a-f, or A-F).\n\nether src ehost\nTrue if the Ethernet source address is ehost.\n\nether host ehost\nTrue if either the Ethernet source or destination address is ehost.\n\ngateway host\nTrue if the packet used host as a gateway.  I.e., the Ethernet source  or  destination\naddress was host but neither the IP source nor the IP destination was host.  Host must\nbe a name and must be found both by the machine's  host-name-to-IP-address  resolution\nmechanisms  (host  name file, DNS, NIS, etc.) and by the machine's host-name-to-Ether‐\nnet-address resolution mechanism (/etc/ethers, etc.).  (An equivalent expression is\nether host ehost and not host host\nwhich can be used with either names or numbers for host / ehost.)   This  syntax  does\nnot work in IPv6-enabled configuration at this moment.\n\ndst net net\nTrue  if  the  IPv4/v6  destination address of the packet has a network number of net.\nNet may be either a name from the networks database (/etc/networks, etc.) or a network\nnumber.   An  IPv4 network number can be written as a dotted quad (e.g., 192.168.1.0),\ndotted triple (e.g., 192.168.1), dotted pair (e.g, 172.16), or  single  number  (e.g.,\n10);  the netmask is 255.255.255.255 for a dotted quad (which means that it's really a\nhost match), 255.255.255.0 for a dotted triple, 255.255.0.0  for  a  dotted  pair,  or\n255.0.0.0  for a single number.  An IPv6 network number must be written out fully; the\nnetmask is ff:ff:ff:ff:ff:ff:ff:ff, so IPv6 \"network\" matches are really  always  host\nmatches, and a network match requires a netmask length.\n\nsrc net net\nTrue if the IPv4/v6 source address of the packet has a network number of net.\n\nnet net\nTrue  if  either the IPv4/v6 source or destination address of the packet has a network\nnumber of net.\n\nnet net mask netmask\nTrue if the IPv4 address matches net with the specific netmask.  May be qualified with\nsrc or dst.  Note that this syntax is not valid for IPv6 net.\n\nnet net/len\nTrue  if  the IPv4/v6 address matches net with a netmask len bits wide.  May be quali‐\nfied with src or dst.\n\ndst port port\nTrue if the packet is IPv4 TCP, IPv4 UDP, IPv6 TCP or IPv6 UDP and has  a  destination\nport  value  of  port.   The port can be a number or a name used in /etc/services (see\ntcp(4P) and udp(4P)).  If a name is used,  both  the  port  number  and  protocol  are\nchecked.   If  a  number  or  ambiguous  name is used, only the port number is checked\n(e.g., `dst port 513' will print both tcp/login traffic and udp/who traffic, and `port\ndomain' will print both tcp/domain and udp/domain traffic).\n\nsrc port port\nTrue if the packet has a source port value of port.\n\nport port\nTrue if either the source or destination port of the packet is port.\n\ndst portrange port1-port2\nTrue  if  the packet is IPv4 TCP, IPv4 UDP, IPv6 TCP or IPv6 UDP and has a destination\nport value between port1 and port2 (both inclusive).  port1 and port2 are  interpreted\nin the same fashion as the port parameter for port.\n\nsrc portrange port1-port2\nTrue if the packet has a source port value between port1 and port2 (both inclusive).\n\nportrange port1-port2\nTrue if either the source or destination port of the packet is between port1 and port2\n(both inclusive).\n\nAny of the above port or port range expressions can be prepended  with  the  keywords,\ntcp or udp, as in:\ntcp src port port\nwhich matches only TCP packets whose source port is port.\n\nless length\nTrue if the packet has a length less than or equal to length.  This is equivalent to:\nlen <= length\n\ngreater length\nTrue  if  the packet has a length greater than or equal to length.  This is equivalent\nto:\nlen >= length\n\nip proto protocol\nTrue if the packet is an IPv4 packet (see ip(4P)) of protocol type protocol.  Protocol\ncan  be a number or one of the names icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp,\nor tcp.  Note that the identifiers tcp, udp, and icmp are also keywords  and  must  be\nescaped  via  backslash  (\\).   Note  that  this primitive does not chase the protocol\nheader chain.\n\nip6 proto protocol\nTrue if the packet is an IPv6 packet of protocol type protocol.  Note that this primi‐\ntive does not chase the protocol header chain.\n\nproto protocol\nTrue  if  the  packet  is an IPv4 or IPv6 packet of protocol type protocol.  Note that\nthis primitive does not chase the protocol header chain.\n\ntcp, udp, icmp\nAbbreviations for:\nproto \\protocol\nwhere protocol is one of the above protocols.\n\nip6 protochain protocol\nTrue if the packet is IPv6 packet, and contains protocol header with type protocol  in\nits protocol header chain.  For example,\nip6 protochain 6\nmatches  any  IPv6  packet with TCP protocol header in the protocol header chain.  The\npacket may contain, for example, authentication header, routing header, or  hop-by-hop\noption header, between IPv6 header and TCP header.  The BPF code emitted by this prim‐\nitive is complex and cannot be optimized by the BPF optimizer code, and  is  not  sup‐\nported  by  filter  engines in the kernel, so this can be somewhat slow, and may cause\nmore packets to be dropped.\n\nip protochain protocol\nEquivalent to ip6 protochain protocol, but this is for IPv4.\n\nprotochain protocol\nTrue if the packet is an IPv4 or IPv6 packet of protocol  type  protocol.   Note  that\nthis primitive chases the protocol header chain.\n",
            "subsections": [
                {
                    "name": "ether broadcast",
                    "content": "True if the packet is an Ethernet broadcast packet.  The ether keyword is optional.\n"
                },
                {
                    "name": "ip broadcast",
                    "content": "True if the packet is an IPv4 broadcast packet.  It checks for both the all-zeroes and\nall-ones broadcast conventions, and looks up the subnet mask on the interface on which\nthe capture is being done.\n\nIf  the  subnet mask of the interface on which the capture is being done is not avail‐\nable, either because the interface on which capture is being done has  no  netmask  or\nbecause  the  capture is being done on the Linux \"any\" interface, which can capture on\nmore than one interface, this check will not work correctly.\n"
                },
                {
                    "name": "ether multicast",
                    "content": "True if the packet is an Ethernet multicast packet.  The ether  keyword  is  optional.\nThis is shorthand for `ether[0] & 1 != 0'.\n"
                },
                {
                    "name": "ip multicast",
                    "content": "True if the packet is an IPv4 multicast packet.\n"
                },
                {
                    "name": "ip6 multicast",
                    "content": "True if the packet is an IPv6 multicast packet.\n\nether proto protocol\nTrue  if the packet is of ether type protocol.  Protocol can be a number or one of the\nnames aarp, arp, atalk, decnet, ip, ip6, ipx, iso, lat, loopback, mopdl,  moprc,  net‐‐\nbeui,  rarp,  sca  or stp.  Note these identifiers (except loopback) are also keywords\nand must be escaped via backslash (\\).\n\n[In the case of FDDI (e.g., `fddi proto \\arp'), Token Ring (e.g.,  `tr  proto  \\arp'),\nand  IEEE 802.11 wireless LANs (e.g., `wlan proto \\arp'), for most of those protocols,\nthe protocol identification comes from the 802.2 Logical Link  Control  (LLC)  header,\nwhich is usually layered on top of the FDDI, Token Ring, or 802.11 header.\n\nWhen  filtering for most protocol identifiers on FDDI, Token Ring, or 802.11, the fil‐\nter checks only the protocol ID field of an LLC header in so-called SNAP  format  with\nan  Organizational  Unit  Identifier  (OUI) of 0x000000, for encapsulated Ethernet; it\ndoesn't check whether the packet is in SNAP format with an OUI of 0x000000.   The  ex‐\nceptions are:\n\niso    the  filter checks the DSAP (Destination Service Access Point) and SSAP (Source\nService Access Point) fields of the LLC header;\n\nstp and netbeui\nthe filter checks the DSAP of the LLC header;\n\natalk  the filter checks for a SNAP-format packet with an OUI of 0x080007 and the  Ap‐\npleTalk etype.\n\nIn  the  case of Ethernet, the filter checks the Ethernet type field for most of those\nprotocols.  The exceptions are:\n\niso, stp, and netbeui\nthe filter checks for an 802.3 frame and then checks the LLC header as it  does\nfor FDDI, Token Ring, and 802.11;\n\natalk  the  filter  checks both for the AppleTalk etype in an Ethernet frame and for a\nSNAP-format packet as it does for FDDI, Token Ring, and 802.11;\n\naarp   the filter checks for the AppleTalk ARP etype in either an Ethernet frame or an\n802.2 SNAP frame with an OUI of 0x000000;\n\nipx    the  filter  checks for the IPX etype in an Ethernet frame, the IPX DSAP in the\nLLC header, the 802.3-with-no-LLC-header encapsulation  of  IPX,  and  the  IPX\netype in a SNAP frame.\n\nip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui\nAbbreviations for:\nether proto \\protocol\nwhere protocol is one of the above protocols.\n\nlat, moprc, mopdl\nAbbreviations for:\nether proto \\protocol\nwhere  protocol  is  one of the above protocols.  Note that not all applications using\npcap(3PCAP) currently know how to parse these protocols.\n\ndecnet src host\nTrue if the DECnet source address is host,  which  may  be  an  address  of  the  form\n``10.123'', or a DECnet host name.  [DECnet host name support is only available on UL‐\nTRIX systems that are configured to run DECnet.]\n\ndecnet dst host\nTrue if the DECnet destination address is host.\n\ndecnet host host\nTrue if either the DECnet source or destination address is host.\n\nllc    True if the packet has an 802.2 LLC header.  This includes:\n\nEthernet packets with a length field rather than a type field that aren't raw NetWare-\nover-802.3 packets;\n\nIEEE 802.11 data packets;\n\nToken Ring packets (no check is done for LLC frames);\n\nFDDI packets (no check is done for LLC frames);\n\nLLC-encapsulated ATM packets, for SunATM on Solaris.\n\nllc type\nTrue  if  the  packet has an 802.2 LLC header and has the specified type.  type can be\none of:\n\ni      Information (I) PDUs\n\ns      Supervisory (S) PDUs\n\nu      Unnumbered (U) PDUs\n\nrr     Receiver Ready (RR) S PDUs\n\nrnr    Receiver Not Ready (RNR) S PDUs\n\nrej    Reject (REJ) S PDUs\n\nui     Unnumbered Information (UI) U PDUs\n\nua     Unnumbered Acknowledgment (UA) U PDUs\n\ndisc   Disconnect (DISC) U PDUs\n\nsabme  Set Asynchronous Balanced Mode Extended (SABME) U PDUs\n\ntest   Test (TEST) U PDUs\n\nxid    Exchange Identification (XID) U PDUs\n\nfrmr   Frame Reject (FRMR) U PDUs\n"
                },
                {
                    "name": "inbound",
                    "content": "Packet was received by the host performing the capture rather than being sent by  that\nhost.   This  is  only  supported  for  certain link-layer types, such as SLIP and the\n``cooked'' Linux capture mode used for the ``any'' device and for  some  other  device\ntypes.\n"
                },
                {
                    "name": "outbound",
                    "content": "Packet  was sent by the host performing the capture rather than being received by that\nhost.  This is only supported for certain link-layer  types,  such  as  SLIP  and  the\n``cooked''  Linux  capture  mode used for the ``any'' device and for some other device\ntypes.\n\nifname interface\nTrue if the packet was logged as coming from the specified interface (applies only  to\npackets logged by OpenBSD's or FreeBSD's pf(4)).\n\non interface\nSynonymous with the ifname modifier.\n\nrnr num\nTrue  if  the packet was logged as matching the specified PF rule number (applies only\nto packets logged by OpenBSD's or FreeBSD's pf(4)).\n\nrulenum num\nSynonymous with the rnr modifier.\n\nreason code\nTrue if the packet was logged with the specified PF reason code.  The known codes are:\nmatch,  bad-offset,  fragment,  short,  normalize, and memory (applies only to packets\nlogged by OpenBSD's or FreeBSD's pf(4)).\n\nrset name\nTrue if the packet was logged as matching the specified PF ruleset name of an anchored\nruleset (applies only to packets logged by OpenBSD's or FreeBSD's pf(4)).\n\nruleset name\nSynonymous with the rset modifier.\n\nsrnr num\nTrue  if the packet was logged as matching the specified PF rule number of an anchored\nruleset (applies only to packets logged by OpenBSD's or FreeBSD's pf(4)).\n\nsubrulenum num\nSynonymous with the srnr modifier.\n\naction act\nTrue if PF took the specified action when the packet was logged.  Known  actions  are:\npass  and  block and, with later versions of pf(4), nat, rdr, binat and scrub (applies\nonly to packets logged by OpenBSD's or FreeBSD's pf(4)).\n\nwlan ra ehost\nTrue if the IEEE 802.11 RA is ehost.  The RA field is used in all  frames  except  for\nmanagement frames.\n\nwlan ta ehost\nTrue  if  the  IEEE 802.11 TA is ehost.  The TA field is used in all frames except for\nmanagement frames and CTS (Clear To Send) and ACK (Acknowledgment) control frames.\n\nwlan addr1 ehost\nTrue if the first IEEE 802.11 address is ehost.\n\nwlan addr2 ehost\nTrue if the second IEEE 802.11 address, if present,  is  ehost.   The  second  address\nfield  is  used  in all frames except for CTS (Clear To Send) and ACK (Acknowledgment)\ncontrol frames.\n\nwlan addr3 ehost\nTrue if the third IEEE 802.11 address, if present, is ehost.  The third address  field\nis used in management and data frames, but not in control frames.\n\nwlan addr4 ehost\nTrue  if  the  fourth  IEEE  802.11 address, if present, is ehost.  The fourth address\nfield is only used for WDS (Wireless Distribution System) frames.\n\ntype wlantype\nTrue if the IEEE 802.11 frame type matches the specified wlantype.  Valid  wlantypes\nare: mgt, ctl and data.\n\ntype wlantype subtype wlansubtype\nTrue  if  the IEEE 802.11 frame type matches the specified wlantype and frame subtype\nmatches the specified wlansubtype.\n\nIf the specified wlantype is mgt, then valid  wlansubtypes  are:  assoc-req,  assoc-\nresp,  reassoc-req,  reassoc-resp, probe-req, probe-resp, beacon, atim, disassoc, auth\nand deauth.\n\nIf the specified wlantype is ctl, then valid wlansubtypes are:  ps-poll,  rts,  cts,\nack, cf-end and cf-end-ack.\n\nIf  the  specified wlantype is data, then valid wlansubtypes are: data, data-cf-ack,\ndata-cf-poll, data-cf-ack-poll, null, cf-ack,  cf-poll,  cf-ack-poll,  qos-data,  qos-\ndata-cf-ack,  qos-data-cf-poll, qos-data-cf-ack-poll, qos, qos-cf-poll and qos-cf-ack-\npoll.\n\nsubtype wlansubtype\nTrue if the IEEE 802.11 frame subtype matches the specified wlansubtype and frame has\nthe type to which the specified wlansubtype belongs.\n\ndir dir\nTrue  if  the IEEE 802.11 frame direction matches the specified dir.  Valid directions\nare: nods, tods, fromds, dstods, or a numeric value.\n\nvlan [vlanid]\nTrue if the packet is an IEEE 802.1Q VLAN packet.  If the optional vlanid  is  speci‐\nfied,  only  true  if  the packet has the specified vlanid.  Note that the first vlan\nkeyword encountered in an expression changes the decoding offsets for the remainder of\nthe  expression  on  the  assumption  that  the  packet  is  a VLAN packet.  The `vlan\n[vlanid]` keyword may be used more than once, to filter on  VLAN  hierarchies.   Each\nuse of that keyword increments the filter offsets by 4.\n\nFor example:\nvlan 100 && vlan 200\nfilters on VLAN 200 encapsulated within VLAN 100, and\nvlan && vlan 300 && ip\nfilters  IPv4  protocol  encapsulated in VLAN 300 encapsulated within any higher order\nVLAN.\n\nmpls [labelnum]\nTrue if the packet is an MPLS packet.  If the optional labelnum  is  specified,  only\ntrue  if the packet has the specified labelnum.  Note that the first mpls keyword en‐\ncountered in an expression changes the decoding offsets for the remainder of  the  ex‐\npression  on  the  assumption  that  the packet is a MPLS-encapsulated IP packet.  The\n`mpls [labelnum]` keyword may be used more than once, to filter on MPLS  hierarchies.\nEach use of that keyword increments the filter offsets by 4.\n\nFor example:\nmpls 100000 && mpls 1024\nfilters packets with an outer label of 100000 and an inner label of 1024, and\nmpls && mpls 1024 && host 192.9.200.1\nfilters  packets  to or from 192.9.200.1 with an inner label of 1024 and any outer la‐\nbel.\n\npppoed True if the packet is a PPP-over-Ethernet Discovery packet (Ethernet type 0x8863).\n\npppoes [sessionid]\nTrue if the packet is a PPP-over-Ethernet Session packet (Ethernet type  0x8864).   If\nthe  optional  sessionid is specified, only true if the packet has the specified ses‐\nsionid.  Note that the first pppoes keyword encountered in an expression changes  the\ndecoding offsets for the remainder of the expression on the assumption that the packet\nis a PPPoE session packet.\n\nFor example:\npppoes 0x27 && ip\nfilters IPv4 protocol encapsulated in PPPoE session id 0x27.\n\ngeneve [vni]\nTrue if the packet is a Geneve packet (UDP port 6081). If the optional vni  is  speci‐\nfied,  only  true if the packet has the specified vni.  Note that when the geneve key‐\nword is encountered in an expression, it changes the decoding offsets for the  remain‐\nder of the expression on the assumption that the packet is a Geneve packet.\n\nFor example:\ngeneve 0xb && ip\nfilters  IPv4  protocol encapsulated in Geneve with VNI 0xb. This will match both IPv4\ndirectly encapsulated in Geneve as well as IPv4 contained inside an Ethernet frame.\n\niso proto protocol\nTrue if the packet is an OSI packet of protocol type protocol.  Protocol can be a num‐\nber or one of the names clnp, esis, or isis.\n\nclnp, esis, isis\nAbbreviations for:\niso proto \\protocol\nwhere protocol is one of the above protocols.\n\nl1, l2, iih, lsp, snp, csnp, psnp\nAbbreviations for IS-IS PDU types.\n\nvpi n  True  if the packet is an ATM packet, for SunATM on Solaris, with a virtual path iden‐\ntifier of n.\n\nvci n  True if the packet is an ATM packet, for SunATM on Solaris,  with  a  virtual  channel\nidentifier of n.\n\nlane   True if the packet is an ATM packet, for SunATM on Solaris, and is an ATM LANE packet.\nNote that the first lane keyword encountered in an expression changes the  tests  done\nin  the remainder of the expression on the assumption that the packet is either a LANE\nemulated Ethernet packet or a LANE LE Control packet.  If lane  isn't  specified,  the\ntests are done under the assumption that the packet is an LLC-encapsulated packet.\n\noamf4s True  if  the  packet is an ATM packet, for SunATM on Solaris, and is a segment OAM F4\nflow cell (VPI=0 & VCI=3).\n\noamf4e True if the packet is an ATM packet, for SunATM on Solaris, and is an  end-to-end  OAM\nF4 flow cell (VPI=0 & VCI=4).\n\noamf4  True  if  the packet is an ATM packet, for SunATM on Solaris, and is a segment or end-\nto-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).\n\noam    True if the packet is an ATM packet, for SunATM on Solaris, and is a segment  or  end-\nto-end OAM F4 flow cell (VPI=0 & (VCI=3 | VCI=4)).\n\nmetac  True if the packet is an ATM packet, for SunATM on Solaris, and is on a meta signaling\ncircuit (VPI=0 & VCI=1).\n\nbcc    True if the packet is an ATM packet, for SunATM on Solaris, and is on a broadcast sig‐\nnaling circuit (VPI=0 & VCI=2).\n\nsc     True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling cir‐\ncuit (VPI=0 & VCI=5).\n\nilmic  True if the packet is an ATM packet, for SunATM on Solaris, and is on an ILMI  circuit\n(VPI=0 & VCI=16).\n"
                },
                {
                    "name": "connectmsg",
                    "content": "True if the packet is an ATM packet, for SunATM on Solaris, and is on a signaling cir‐\ncuit and is a Q.2931 Setup, Call Proceeding, Connect, Connect Ack, Release, or Release\nDone message.\n"
                },
                {
                    "name": "metaconnect",
                    "content": "True if the packet is an ATM packet, for SunATM on Solaris, and is on a meta signaling\ncircuit and is a Q.2931 Setup, Call Proceeding, Connect, Release, or Release Done mes‐\nsage.\n\nexpr relop expr\nTrue  if the relation holds, where relop is one of >, <, >=, <=, =, !=, and expr is an\narithmetic expression composed of integer constants (expressed in standard C  syntax),\nthe  normal  binary operators [+, -, *, /, %, &, |, ^, <<, >>], a length operator, and\nspecial packet data accessors.  Note that all comparisons are unsigned, so  that,  for\nexample, 0x80000000 and 0xffffffff are > 0.\n\nThe  %  and  ^  operators  are currently only supported for filtering in the kernel on\nLinux with 3.7 and later kernels; on all other systems, if those operators  are  used,\nfiltering  will  be  done  in user mode, which will increase the overhead of capturing\npackets and may cause more packets to be dropped.\n\nTo access data inside the packet, use the following syntax:\nproto [ expr : size ]\nProto is one of ether, fddi, tr, wlan, ppp, slip, link, ip, arp, rarp, tcp, udp, icmp,\nip6 or radio, and indicates the protocol layer for the index operation.  (ether, fddi,\nwlan, tr, ppp, slip and link all refer to the link layer. radio refers to  the  \"radio\nheader\" added to some 802.11 captures.)  Note that tcp, udp and other upper-layer pro‐\ntocol types only apply to IPv4, not IPv6 (this will be fixed in the future).  The byte\noffset,  relative to the indicated protocol layer, is given by expr.  Size is optional\nand indicates the number of bytes in the field of interest; it can be either one, two,\nor  four,  and  defaults  to  one.  The length operator, indicated by the keyword len,\ngives the length of the packet.\n\nFor example, `ether[0] & 1 != 0' catches all multicast traffic.  The expression `ip[0]\n& 0xf != 5' catches all IPv4 packets with options.  The expression `ip[6:2] & 0x1fff =\n0' catches only unfragmented IPv4 datagrams and frag zero  of  fragmented  IPv4  data‐\ngrams.  This check is implicitly applied to the tcp and udp index operations.  For in‐\nstance, tcp[0] always means the first byte of the TCP  header,  and  never  means  the\nfirst byte of an intervening fragment.\n\nSome offsets and field values may be expressed as names rather than as numeric values.\nThe following protocol header field offsets are available: icmptype (ICMP type field),\nicmp6type  (ICMPv6  type  field),  icmpcode  (ICMP code field), icmp6code (ICMPv6 code\nfield) and tcpflags (TCP flags field).\n\nThe following ICMP type field  values  are  available:  icmp-echoreply,  icmp-unreach,\nicmp-sourcequench,  icmp-redirect,  icmp-echo,  icmp-routeradvert, icmp-routersolicit,\nicmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq,  icmp-ireqre‐‐\nply, icmp-maskreq, icmp-maskreply.\n\nThe following ICMPv6 type fields are available: icmp6-destinationrunreach, icmp6-pack‐‐\nettoobig,  icmp6-timeexceeded,  icmp6-parameterproblem,  icmp6-echo,  icmp6-echoreply,\nicmp6-multicastlistenerquery,  icmp6-multicastlistenerreportv1, icmp6-multicastlisten‐‐\nerdone, icmp6-routersolicit, icmp6-routeradvert, icmp6-neighborsolicit, icmp6-neighbo‐‐\nradvert,  icmp6-redirect, icmp6-routerrenum, icmp6-nodeinformationquery, icmp6-nodein‐‐\nformationresponse,  icmp6-ineighbordiscoverysolicit,   icmp6-ineighbordiscoveryadvert,\nicmp6-multicastlistenerreportv2,  icmp6-homeagentdiscoveryrequest, icmp6-homeagentdis‐‐\ncoveryreply,  icmp6-mobileprefixsolicit,  icmp6-mobileprefixadvert,  icmp6-certpathso‐‐\nlicit,   icmp6-certpathadvert,  icmp6-multicastrouteradvert,  icmp6-multicastrouterso‐‐\nlicit, icmp6-multicastrouterterm.\n\nThe following TCP flags field values are available: tcp-fin,  tcp-syn,  tcp-rst,  tcp-\npush, tcp-ack, tcp-urg, tcp-ece, tcp-cwr.\n\nPrimitives may be combined using:\n\nA parenthesized group of primitives and operators.\n\nNegation (`!' or `not').\n\nConcatenation (`&&' or `and').\n\nAlternation (`||' or `or').\n\nNegation has the highest precedence.  Alternation and concatenation have equal precedence and\nassociate left to right.  Note that explicit and tokens, not juxtaposition, are now  required\nfor concatenation.\n\nIf  an  identifier is given without a keyword, the most recent keyword is assumed.  For exam‐\nple,\nnot host vs and ace\nis short for\nnot host vs and host ace\nwhich should not be confused with\nnot (host vs or ace)\n"
                }
            ]
        },
        "EXAMPLES": {
            "content": "To select all packets arriving at or departing from `sundown':\nhost sundown\n\nTo select traffic between `helios' and either `hot' or `ace':\nhost helios and (hot or ace)\n\nTo select all IPv4 packets between `ace' and any host except `helios':\nip host ace and not helios\n\nTo select all traffic between local hosts and hosts at Berkeley:\nnet ucb-ether\n\nTo select all FTP traffic through Internet gateway `snup':\ngateway snup and (port ftp or ftp-data)\n\nTo select IPv4 traffic neither sourced from nor destined for local hosts (if you  gateway  to\none other net, this stuff should never make it onto your local net).\nip and not net localnet\n\nTo  select  the start and end packets (the SYN and FIN packets) of each TCP conversation that\ninvolves a non-local host.\ntcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet\n\nTo select the TCP packets with flags RST and ACK both set.  (i.e. select only the RST and ACK\nflags in the flags field, and if the result is \"RST and ACK both set\", match)\ntcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)\n\nTo  select  all  IPv4  HTTP packets to and from port 80, i.e. print only packets that contain\ndata, not, for example, SYN and FIN packets and ACK-only packets.  (IPv6 is left as an  exer‐\ncise for the reader.)\ntcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)\n\nTo select IPv4 packets longer than 576 bytes sent through gateway `snup':\ngateway snup and ip[2:2] > 576\n\nTo  select  IPv4  broadcast or multicast packets that were not sent via Ethernet broadcast or\nmulticast:\nether[0] & 1 = 0 and ip[16] >= 224\n\nTo select all ICMP packets that are not echo requests/replies (i.e., not ping packets):\nicmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply\nicmp6[icmp6type] != icmp6-echo and icmp6[icmp6type] != icmp6-echoreply\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "pcap(3PCAP)\n",
            "subsections": []
        },
        "BUGS": {
            "content": "To report a security issue please send an e-mail to security@tcpdump.org.\n\nTo report bugs and other problems, contribute patches, request  a  feature,  provide  generic\nfeedback etc please see the file CONTRIBUTING.md in the libpcap source tree root.\n\nFilter expressions on fields other than those in Token Ring headers will not correctly handle\nsource-routed Token Ring packets.\n\nFilter expressions on fields other than those in 802.11 headers  will  not  correctly  handle\n802.11 data packets with both To DS and From DS set.\n\n`ip6  proto'  should chase header chain, but at this moment it does not.  `ip6 protochain' is\nsupplied for this behavior.  For example, to match IPv6 fragments: `ip6 protochain 44'\n\nArithmetic expression against transport layer headers, like tcp[0],  does  not  work  against\nIPv6 packets.  It only looks at IPv4 packets.\n\n\n\n6 February 2021                            PCAP-FILTER(7)",
            "subsections": []
        }
    },
    "summary": "pcap-filter - packet filter syntax",
    "flags": [],
    "examples": [
        "To select all packets arriving at or departing from `sundown':",
        "host sundown",
        "To select traffic between `helios' and either `hot' or `ace':",
        "host helios and (hot or ace)",
        "To select all IPv4 packets between `ace' and any host except `helios':",
        "ip host ace and not helios",
        "To select all traffic between local hosts and hosts at Berkeley:",
        "net ucb-ether",
        "To select all FTP traffic through Internet gateway `snup':",
        "gateway snup and (port ftp or ftp-data)",
        "To select IPv4 traffic neither sourced from nor destined for local hosts (if you  gateway  to",
        "one other net, this stuff should never make it onto your local net).",
        "ip and not net localnet",
        "To  select  the start and end packets (the SYN and FIN packets) of each TCP conversation that",
        "involves a non-local host.",
        "tcp[tcpflags] & (tcp-syn|tcp-fin) != 0 and not src and dst net localnet",
        "To select the TCP packets with flags RST and ACK both set.  (i.e. select only the RST and ACK",
        "flags in the flags field, and if the result is \"RST and ACK both set\", match)",
        "tcp[tcpflags] & (tcp-rst|tcp-ack) == (tcp-rst|tcp-ack)",
        "To  select  all  IPv4  HTTP packets to and from port 80, i.e. print only packets that contain",
        "data, not, for example, SYN and FIN packets and ACK-only packets.  (IPv6 is left as an  exer‐",
        "cise for the reader.)",
        "tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)",
        "To select IPv4 packets longer than 576 bytes sent through gateway `snup':",
        "gateway snup and ip[2:2] > 576",
        "To  select  IPv4  broadcast or multicast packets that were not sent via Ethernet broadcast or",
        "multicast:",
        "ether[0] & 1 = 0 and ip[16] >= 224",
        "To select all ICMP packets that are not echo requests/replies (i.e., not ping packets):",
        "icmp[icmptype] != icmp-echo and icmp[icmptype] != icmp-echoreply",
        "icmp6[icmp6type] != icmp6-echo and icmp6[icmp6type] != icmp6-echoreply"
    ],
    "see_also": [
        {
            "name": "pcap",
            "section": "3PCAP",
            "url": "https://www.chedong.com/phpMan.php/man/pcap/3PCAP/json"
        }
    ]
}