tcpdump / pcap Viewer v0.3.0

Added

• Options dialog. Configure… on the plugin's card in Plugins →
  Plugin Management… opens the plugin's options: the time columns (UTC
  time and time since the first packet, UTC time only, or time since the
  first packet only), MAC addresses as columns (Source MAC and
  Destination MAC before Info), the payload preview on or off and its
  length up to 200 characters, and, under Advanced, the stream and
  endpoint caps. They are kept in settings.ini in the plugin's
  configuration directory and read when a capture is opened; a capture
  already open keeps the options it was converted with. The defaults write
  the packet list as before. The Log Format also reads the lines of the
  other time and MAC choices, a missing time column left empty, the MAC
  addresses as the start of Info; README's Options says which choices
  change the columns that highlighters and filters may rely on.
• DHCP, DHCPv6 and NTP described. DHCP Info names the message type as
  Wireshark does, with the transaction id, the address assigned, requested
  or held and the client's MAC, and the host name the client sends: DHCP Offer - Transaction ID 0x3903f326, 192.168.1.50 for 00:11:22:33:44:55,
  DHCP Discover - Transaction ID 0x3903f326 from 00:11:22:33:44:55, Host Name: laptop; messages without a DHCP message type are Boot Request
  or Boot Reply. Options are walked within the message, pads, the end
  option and overloaded file and sname fields included; a length that runs
  past the message ends the walk. DHCPv6 (546/547) names its message type,
  transaction id and client DUID, Solicit XID: 0x1a2b3c CID: 0001…, and
  relay messages the link and the message they carry; it is now DHCPv6
  by its port, as DHCP is, rather than a port guess with a preview of the
  bytes. NTP shows version, mode and stratum, NTP Version 4, server, stratum 2, with the reference of a primary server or a kiss-o'-death
  code, stratum 1 (GPS). Before, DHCP and NTP lines had no description.
• ICMP and ICMPv6 in full. Info names messages in Wireshark's words. An
  echo shows its identifier and sequence number, so request and reply pair
  up: Echo (ping) request id=0x1234, seq=7 (before: Echo request); so do
  timestamp, information and address mask queries. Destination unreachable,
  time exceeded, parameter problem and redirect name their code and the
  packet they quote, dissected with the same IP parsers: Destination unreachable (Port unreachable) for 10.0.0.1:51234 → 192.168.1.5:53 UDP,
  Time exceeded (TTL exceeded in transit) for …, with the next hop's MTU
  of a fragmentation needed and the gateway of a redirect (before:
  Destination unreachable (code=3), Time exceeded). ICMPv6 names its
  error codes the same way, Packet too big mtu=1280 for …, a neighbor
  solicitation or advertisement its target, flags and link-layer address,
  Neighbor advertisement fe80::2 (rtr, sol, ovr) is at 00:11:22:33:44:55,
  a router advertisement its flags and lifetime, Router advertisement (M, O) lifetime=1800s, and multicast listener messages by name (before:
  Type=143). A quote cut short shows what it holds; it is never read past
  the captured bytes.
• HTTP names the host, the content type and length. A request line
  shows the Host header's value before its path, GET example.com/index.html HTTP/1.1, when the header is in the segment; a
  response adds its Content-Type and Content-Length when it has them,
  HTTP/1.1 200 OK, Content-Type: text/html, Content-Length: 1234. The
  request or status line still comes first, and header values are escaped
  and cut like every field. SSDP responses gain the same headers.
• HTTP/2 in clear text. The connection preface is labelled HTTP2,
  Magic, SETTINGS[0], WINDOW_UPDATE[0], and the segments that follow on
  its stream, in both directions, are HTTP2 when they begin with frame
  headers, each frame named with its type and stream, HEADERS[1], DATA[1]. Header blocks are not decoded, and a segment that begins inside
  a frame is left as it was.
• DNS reads like Wireshark's. A query shows its transaction id, query
  type and name, Standard query 0x1a2b A www.example.com; a response adds
  its answers with their data, Standard query response 0x1a2b A www.example.com CNAME example.com A 93.184.216.34, with names put
  together from their compression pointers. Addresses, names (CNAME, PTR,
  NS, SOA), MX, SRV and TXT data are shown, other record types by name, up
  to four answers, then … and the count. NOTIFY and UPDATE are named, and
  [NXDOMAIN], [SERVFAIL], [REFUSED] and the other response codes stay.
  A pointer that loops, points forward or beyond the message ends the
  description there, never reading past the payload.
• DNS over TCP. Segments to or from TCP port 53 that begin with a DNS
  message behind its 2-byte length are labelled DNS and described like
  DNS over UDP; several messages in one segment are listed in order.
• QUIC on UDP. A datagram that begins with a QUIC long header of v1, v2
  or a draft version is labelled QUIC and described from its public
  header, Initial, Version 1, DCID=8394c8f03e515708, SCID=0a0b0c0d: the
  packet types of the datagram in order (Initial, 0-RTT, Handshake, Retry,
  Protected Payload), the version and the connection IDs. A Version
  Negotiation packet lists the versions the server offers. The short header
  packets that follow on the same stream are QUIC too, Protected Payload, DCID=…, with the connection ID the other side chose. Port 443
  alone does not make a datagram QUIC; the server name is out of reach, as
  it is encrypted even in the Initial.
• TLS hellos name the server, the version and ALPN. A ClientHello line
  shows the server name the client asks for, the highest version it offers
  and its application protocols, Client Hello, SNI=example.com, TLS 1.3, ALPN=h2,http/1.1; an extension the hello lacks is left out. A
  ServerHello shows the version chosen, Server Hello, TLS 1.3. A segment
  holding several records, or a record several handshake messages, lists
  them in order, Server Hello, TLS 1.3, Change Cipher Spec, Application Data, up to four, then …; a handshake record after Change Cipher Spec
  is an Encrypted Handshake Message. A record cut by the snaplen or the
  segment is described as far as it was captured, never read beyond.
• Names for IP protocols, EtherTypes and more ports. A packet that is not
  dissected further shows its protocol's name instead of a number: IGMP
  instead of IP(2), and likewise GRE, ESP, AH, OSPF, PIM, VRRP, L2TP, SCTP
  and others; LLDP instead of ETH(0x88CC), and likewise PPPoE discovery
  and session (PPPoED, PPPoES), MPLS, 802.1X (EAPOL), PTP, Wake-on-LAN
  (WOL) and others. The number stays in the Info column, and an unknown
  one keeps its numeric form. An IEEE 802.3 frame, whose type field is a
  length, shows as LLC. The port hint learns SNMP, Syslog, TFTP,
  STUN/TURN, WireGuard, LLMNR, NBNS, DHCPv6, RTSP, LDAP, SMB, RDP, VNC,
  Kerberos and some sixty more services.
• The protocol sticks to the stream. Once a detector has recognised a
  TCP or UDP stream's protocol (TLS, HTTP, SOCKS, NMEA, …), its later
  packets carry the same label in the Protocol column, also those no
  detector recognises: a segment in the middle of a TLS record or an HTTP
  body, a bare ACK. A segment with payload is described as Continuation,
  followed by its preview when it has text. A port's guess (HTTPS,
  HTTP-Alt) never sticks and gives way to the first recognised protocol;
  a new connection on the same addresses and ports starts without a label.
  So filtering by Protocol finds the whole conversation, and the protocol
  breakdown in the Capture Summary counts it whole. Each numbered stream
  takes 8 bytes more memory.
• TCP analysis markers. TCP lines carry Wireshark's expert markers at
  the start of Info, in its words and order: [TCP Retransmission],
  [TCP Fast Retransmission], [TCP Spurious Retransmission],
  [TCP Out-Of-Order], [TCP Previous segment not captured],
  [TCP Dup ACK n#m], [TCP Window Update], [TCP ZeroWindow],
  [TCP ZeroWindowProbe], [TCP ZeroWindowProbeAck], [TCP Keep-Alive]
  and [TCP Keep-Alive ACK], by Wireshark's rules as far as a few numbers
  per direction of a stream allow (the Developer Guide lists the limits).
  The Capture Summary counts the segments per marker under Analysis. Each
  numbered stream takes 48 bytes more memory, some 48 MB at the stream cap.
• Relative TCP sequence and acknowledgement numbers. Seq= and Ack=
  in Info count from the start of each direction of a TCP stream, as
  Wireshark shows them by default: the SYN is Seq=0, the first byte of
  data Seq=1. A stream captured mid-way counts from its first segment seen
  (Seq=1 Ack=1), the numbers go on counting when the sequence numbers wrap
  past 2^32, and a new connection on the same addresses and ports starts
  afresh. A segment without the ACK flag shows Ack=0. Streams past the
  stream cap keep the numbers as they are.
• pcapng captures. Files saved by Wireshark (its default format) or by
  macOS's tcpdump -P open like a pcap, in either byte order and with several
  sections. Each packet is dissected with the link type of the interface it
  was captured on and shown at that interface's timestamp resolution
  (if_tsresol), so a capture of an Ethernet and a Raw IP interface, or of a
  microsecond and a nanosecond one, reads right; the Capture Summary lists
  every link type. Name resolution, statistics, custom and other blocks are
  skipped. A pcapng without packets converts to just the header line, and one
  that is cut off is reported like a cut-off pcap. The file dialog offers
  .pcapng.
• Log Format for the packet list. formats/tcpdump_log.json, an
  lnav-compatible Log Format definition, names t...

tcpdump / pcap Viewer v0.2.0

Added

• SOCKS4 and SOCKS5 handshakes are described on the usual proxy ports
  (1080, 1081, 3128, 9050, 9051): greeting and method choice, connect, bind
  and UDP associate requests and their replies with destination and bound
  address, SOCKS4/4a requests with user id and domain, and the RFC 1929
  username/password exchange — user name and password included, since they
  cross the wire in clear text. Only messages whose length matches their
  fields exactly, travelling towards or away from the proxy port as they
  should, are labelled.
• Nanosecond captures. Files with nanosecond timestamps (magic
  0xa1b23c4d, e.g. from tcpdump --time-stamp-precision=nano) are read in
  either byte order, and their Time column shows nine decimals.
• Progress and Cancel. While a capture is read, the sidebar shows a
  progress bar and a Cancel button.
• IPv6 extension headers (hop-by-hop, routing, fragment, destination options,
  authentication) are walked to the TCP, UDP or ICMPv6 layer behind them.
• Stacked VLAN tags are stripped, including 802.1ad (QinQ) service tags
  (0x88a8, 0x9100), also in Linux cooked captures.
• DLT_LOOP loopback captures are read.
• The sidebar summary says when a capture ends in the middle of a packet.

Changed

• Requires LogSquirl 26.10.0 or later. This release is built with the Qt of
  LogSquirl 26.10.0 (Qt 6.11.3); an older LogSquirl cannot load it.
• The payload preview shows every byte from the start of the payload,
  printable ones as themselves and all others as a dot, instead of skipping
  to the first run of text and collapsing binary runs to a space. It stops
  after 200 characters with an ellipsis, and payloads that are mostly binary
  still get none.
• Each capture's text is written to its own new file, <name>.log, in a
  new logsquirl-tcpdump-<pid>-XXXXXX directory in the temporary directory
  that only you can enter, and removed when LogSquirl quits. When the plugin
  is disabled or updated while LogSquirl keeps running, the files are kept
  for the tabs that still show them, and the plugin, once enabled again,
  still removes them at quit. Directories left behind by a LogSquirl that no
  longer runs, e.g. after a crash, are removed when the plugin starts.
• A pcap header past the start of the file is accepted only behind text, as
  tcpdump's stderr puts it there, and only if it is a valid header; a stray
  magic number in other data is no longer taken for a capture. A file with a
  pcap format version other than 2.x is rejected with that version named.
• Bytes outside printable ASCII in HTTP lines, DNS names, NMEA sentences and
  SOCKS fields are shown as \xNN, so every packet stays on one line.

Fixed

• Large captures no longer freeze or crash LogSquirl. The whole file was
  read into memory, every packet copied once more, and all lines formatted on
  the GUI thread before any was written, so a multi-GB capture froze
  LogSquirl and then took it down when memory ran out. Captures are now read,
  formatted and written packet by packet on a worker thread, and a corrupt
  packet length no longer makes the plugin allocate up to 4 GiB. Stream
  numbers are given to the first 1,000,000 conversations and endpoints are
  counted for the first 100,000 addresses, so a port scan cannot exhaust
  memory either; later conversations show stream ?, further addresses are
  counted as other endpoints, and the summary says when either happened.
• The temporary text file could be used against you. It had a fixed name
  in the shared temporary directory, was opened with truncation and readable
  by everyone: another local user could have it overwrite a file of theirs
  choosing through a symlink, or read your capture's text. A second capture
  with the same name also overwrote the file a tab still showed, and nothing
  ever removed the files.
• Ethernet padding and link-layer trailers are no longer counted as payload:
  transport data ends where the IPv4 total length or IPv6 payload length
  says. Outgoing packets captured with TSO/GSO, whose lengths read 0, fall
  back to the captured bytes as in Wireshark.
• BSD loopback (DLT_NULL) captures from a big-endian machine were dissected as
  IPv6 throughout, because the address family was read in the byte order of
  the machine running LogSquirl. It is now read in the capture's byte order,
  and the AF_INET6 values of the BSDs and macOS (24, 28, 30) are recognised;
  an unknown family is shown as such instead of being taken for IPv6.
• IPv4 fragments after the first, and IPv6 fragments with a non-zero offset,
  are shown as fragments instead of being parsed as TCP or UDP with ports
  and flags made up from payload bytes.
• A TCP header shorter than 20 bytes is flagged as bogus, and no payload is
  taken from it; before, its header bytes were shown as payload.
• A packet earlier than the first one shows its negative relative time
  instead of 0, and the summary's duration is measured from the earliest to
  the latest packet, so a capture out of time order no longer shows a
  duration of about 136 years.
• File names, protocol names and addresses in the sidebar summary are no
  longer rendered as markup.
• Log messages, notifications and the path of the opened text file reach
  LogSquirl as UTF-8, so captures in folders with non-ASCII names open and
  are reported correctly on systems whose local encoding is not UTF-8.
• No exception can escape into LogSquirl from the plugin's entry points or
  the conversion; a failing initialisation is logged and cleaned up.
• Shutting the plugin down while a capture is being read stops the reading
  and waits for it.

Verifying downloads

Every archive is listed in logsquirl-tcpdump-0.2.0-sha256.txt. That file is
signed with Sigstore (logsquirl-tcpdump-0.2.0-sha256.txt.sigstore.json), and
every archive carries a GitHub build provenance attestation from the shared
LogSquirl plugin release workflow.

# 1. Check the signature of the checksum file (needs cosign)
cosign verify-blob \
  --bundle logsquirl-tcpdump-0.2.0-sha256.txt.sigstore.json \
  --certificate-identity-regexp '^https://github\.com/64x-lunicorn/LogSquirl-Plugin-CI/\.github/workflows/plugin-release\.yml@.+$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-github-workflow-repository 64x-lunicorn/LogSquirl-tcpdump \
  logsquirl-tcpdump-0.2.0-sha256.txt

# 2. Check the archives you downloaded against it
sha256sum -c logsquirl-tcpdump-0.2.0-sha256.txt --ignore-missing

# 3. Or check one archive's build provenance (needs the GitHub CLI)
gh attestation verify <file> -R 64x-lunicorn/LogSquirl-tcpdump \
  --signer-workflow 64x-lunicorn/LogSquirl-Plugin-CI/.github/workflows/plugin-release.yml

tcpdump Plugin v0.1.1

What's Changed

• build(deps): bump softprops/action-gh-release from 2 to 3 by @dependabot[bot] in #2
• build(deps): bump actions/upload-artifact from 4 to 7 by @dependabot[bot] in #1
• build(deps): bump actions/checkout from 6 to 7 by @dependabot[bot] in #3
• Package the plugin library, verify downloads, ship the icon and the full license by @64x-lunicorn in #5

New Contributors

• @dependabot[bot] made their first contribution in #2
• @64x-lunicorn made their first contribution in #5

Full Changelog: v0.1.0...v0.1.1

tcpdump Plugin v0.1.0

Warning

Do not use this release. These archives contain plugin.json and an
empty build/ directory — the plugin library is missing on all three
platforms, so the plugin cannot load. Use
v0.1.1
instead. This release has been removed from the plugin catalog.

---

Full Changelog: https://github.com/64x-lunicorn/LogSquirl-tcpdump/commits/v0.1.0