From nobody Tue Apr 23 14:50:33 2024 X-Original-To: stable@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 4VP4mh1bFzz5HPZH for ; Tue, 23 Apr 2024 14:50:44 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [204.27.62.58]) (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 4VP4mg12wcz4tqg for ; Tue, 23 Apr 2024 14:50:43 +0000 (UTC) (envelope-from mgrooms@shrew.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=shrew.net header.s=default header.b=dnN2oGN6; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 204.27.62.58 as permitted sender) smtp.mailfrom=mgrooms@shrew.net Received: from mail.shrew.net (mail1.shrew.prv [10.26.2.18]) by mx2.shrew.net (8.17.1/8.17.1) with ESMTP id 43NEoYqS019824 for ; Tue, 23 Apr 2024 09:50:34 -0500 (CDT) (envelope-from mgrooms@shrew.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shrew.net; s=default; t=1713883834; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LUwT7o3iwpBmb4fHOg1SsdOophJbO2dQyndKL8/h/hM=; b=dnN2oGN6C8NdZ7eC4VMa9PLBOaJ+/VgCtp3cKeo9iku4U1B7ygNgEfPd2SX1kxuVvuUcfi EgGu8MtecQJ39Pi+WQcWMs2lD2aIL1Rm3x8NBVsxnAqrlNJBeJ6SEAoY5pzpXw1EluFM5v z+Nv8na5GLM5OJS8PQwXiE1HYAB8naGaZDJ4HuEi9VfTizZjN+jSExyoLUz0eWxUcgJ5bR b6C9iNBJHUlpxK7B6JZ40s6H7v1ZTeTUkumayfeadpE5NjTwGPrHVQp5s2mzoNqjrZSMFK fu//qw2GvcFqF6tVw1LO+KYNgzOmjzO8ljrdm98BQnxVuFapsKR5Mh2h4wM2KA== Received: from [10.22.200.32] (unknown [136.62.156.42]) by mail.shrew.net (Postfix) with ESMTPSA id 9DB363B5FC for ; Tue, 23 Apr 2024 09:50:34 -0500 (CDT) Message-ID: <922446cd-4511-4132-8e8f-9c9144a7f9b1@shrew.net> Date: Tue, 23 Apr 2024 09:50:33 -0500 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: possible regression handling packet fragmentation in 14.0 with tftp/pxe To: stable@freebsd.org References: <20240419153951.5a23ce5f@arc.aei.uni-hannover.de> <86y1999wwe.fsf@ltc.des.dev> <20240422075948.5bb856ac@arc.aei.uni-hannover.de> <86o7a18ppl.fsf@ltc.des.dev> <20240423071923.52b90652@arc.aei.uni-hannover.de> Content-Language: en-US From: Matthew Grooms In-Reply-To: <20240423071923.52b90652@arc.aei.uni-hannover.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.47 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.984]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[shrew.net:s=default]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:19969, ipnet:204.27.56.0/21, country:US]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[shrew.net]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[stable@freebsd.org]; DKIM_TRACE(0.00)[shrew.net:+] X-Rspamd-Queue-Id: 4VP4mg12wcz4tqg Sorry. I didn't missed some of the previous details here, but I see you mention pf below. Did you happen to see this? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276856 -Matthew On 4/23/24 00:19, Gerrit Kühn wrote: > Am Mon, 22 Apr 2024 15:57:42 +0200 > schrieb Dag-Erling Smørgrav : > >> Off the top of my head, it means the packet length according to its >> header is longer than the capture length but the MF flag is not set. >> Historically, it meant you needed to increase tcpdump's snaplen, but >> these days it defaults to 256 kB so it shouldn't matter. It might be a >> bug in bpf, or an interaction between pf and bpf. > So maybe this is rather a red herring than a pointer to the actual > difference in packet handling. > >> There were changes in tftpd, but I don't know if that's relevant. > Most certainly not as I didn't touch the server side. The tftpd there is > certainly old, but it worked fine up to FreeBSD 13.3 on the router. It is > the update to 14.0 that triggered the problem. > > > cu > Gerrit