From nobody Fri Sep 12 02:24:36 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cNJD76Mnlz62YLl for ; Fri, 12 Sep 2025 02:24:55 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from mail.sermon-archive.info (sermon-archive.info [47.181.130.121]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4cNJD63Gqkz3XlY for ; Fri, 12 Sep 2025 02:24:54 +0000 (UTC) (envelope-from bc979@lafn.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bc979@lafn.org designates 47.181.130.121 as permitted sender) smtp.mailfrom=bc979@lafn.org Received: from smtpclient.apple (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 4cNJCz0GZ7z1tDrD for ; Thu, 11 Sep 2025 19:24:47 -0700 (PDT) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: TCP State Question Message-Id: <0E3CA9D9-9EC5-49A8-B971-12729FB02EB2@sermon-archive.info> Date: Thu, 11 Sep 2025 19:24:36 -0700 To: "freebsd-net@FreeBSD.org" X-Mailer: Apple Mail (2.3826.700.81) X-Virus-Scanned: clamav-milter 1.4.3 at mail X-Virus-Status: Clean X-Spamd-Bar: / X-Spamd-Result: default: False [0.76 / 15.00]; NEURAL_SPAM_LONG(0.98)[0.985]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; NEURAL_SPAM_SHORT(0.85)[0.849]; R_SPF_ALLOW(-0.20)[+mx]; ONCE_RECEIVED(0.20)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:5650, ipnet:47.181.128.0/18, country:US]; RCVD_COUNT_ONE(0.00)[1]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; APPLE_MAILER_COMMON(0.00)[]; DMARC_NA(0.00)[lafn.org: no valid DMARC record]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4cNJD63Gqkz3XlY I am confused about the pftop output shown below. In both cases there = are significant differences between the source and destination states. = In both cases the source is a remote client and the destination is my = server. Referring to the TCP state diagram from TCP/IP Illustrated, = Volumes 1 and 2, I don't see how the two sides could get that far apart. PR D SRC DEST STATE AGE EXP = PKTS BYTES tcp I 202.133.61.102:18950 10.0.1.230:25 9:4 472 735 = 15 1296 In the case above the source is in FIN_WAIT_2. The destination is in = ESTABLISHED. This implies that the source sent a FIN that the = destination never received. The source should then be in FIN_WAIT_1. = In order for the source to move to FIN_WAIT_2 it needed to receive an = ACK from the destination. However, if the destination had sent an ACK, = it would be in CLOSE_WAIT.=20 PR D SRC DEST STATE AGE EXP = PKTS BYTES tcp I 34.141.245.225:57456 10.0.1.230:25 4:9 27 894 = 15 1329 In this case above, the states are reversed. This is even more = confusing as it shows the destination in FIN_WAIT_2. However, to get = there it would have to go through FIN_WAIT_1. Both of those states are = for the client, not the server. I have not managed to catch the = destination states of CLOSE_WAIT or LAST_ACK which are the server states = during the connection teardown. I only see the client states for the = destination. I will admit that I have not really dealt with the TCP internals since = the early 90's where the company I worked for used the Motorola TCP/IP = stack which was stripped down for use in imbedded systems. I am sure = things have changed a bit since then, but the states I am seeing seem a = bit unusual and contrary to the documentation I have available. -- Doug