From nobody Fri Mar 17 13:18:37 2023 X-Original-To: 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 4PdPpP5BS4z3yMXP for ; Fri, 17 Mar 2023 13:18:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PdPpP1zttz3rwY for ; Fri, 17 Mar 2023 13:18:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1679059117; 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=pWy2FX+3RYSlHMNu0ZtWUMaKL3jHlu7+QiqvBa6wVFk=; b=B9wxsKrhVTqlqMFJw03ES6jSoXNV4o6bIot6mUgjAIJDXEJu4cEBD+D0qf1nXrbv6Fcu1u xx92k+2MihEyI36yl3srhoybeCrtNk+PY9zDyOKgRw7iz0opNtWdgcsis9wYUjGk30hI6m 8RWLaCi+gcECtEUG+sa2lXY4ZT1bsufu2NJEtPst5ZGIFtMi/C1bBvtLa3pdYZktXOcu6K 1Wo8jPzKvy8lc9BH+CzqkSFupZk11GYXDQGFKJv9T+062lBbVYnNTkPwZGOj7x5OXlhPTU JLLBTe5H2sYukbJG1mOaBuRkSTaKNJd2IrSZfMHPeKsv7mH4G4ISL+TOAg0gfw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1679059117; a=rsa-sha256; cv=none; b=maMjf0c8QjAYfqQXVvqXewx+/Qf/pswshpYgVuprMWh9LRScLaJVR2BNF2q9OWVMRZQ3Yc dU7YKtNM+Yhewxk4aXx5KDWY1rvy01nBYASWzFWdtAoZKv6I4cNBLFfpD/AY80Gl8cuk/h ZedHSh4Jd6eZqCxxZ3d/BZkNDaViGUfcEtrPfacQhR4yqWoKFqHlly+L2qGSE0x2psFNzx EZIvt9uGBDTf+wUZg1WGIrKcr9v85G3xJjJ+yWT/2YY/XcoKSbAg98ITWxVX0sgRz9Ho/r yF+7XKtbHfcux7J2ikNcIfnhGhmtam6ecutBJOl/fj2wU5pDJs7tP4NVry8IYQ== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4PdPpP14lVzRYr for ; Fri, 17 Mar 2023 13:18:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 32HDIbxw063061 for ; Fri, 17 Mar 2023 13:18:37 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 32HDIbtZ063060 for net@FreeBSD.org; Fri, 17 Mar 2023 13:18:37 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 270285] Network issue with very small frames (tcp, padded) Date: Fri, 17 Mar 2023 13:18:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.3-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: mhaarmann@midoco.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270285 --- Comment #2 from Marcus Haarmann --- Yes, packet also looks ok for me, the question is why the traffic forwarded= to the client includes these two 0 bytes in the middle of the payload. (pfsense/freebsd reorders the traffic and as a result, we are getting diffe= rent frame sizes in output). So some part in the code does not the respect the actual length but seems to read the whole segment starting from the payload. The whole setup is: Server (10GBit)=20 -> Switch1=20 -> Switch2=20 -> pfSense LAN (GBit) <--- here we can see the small packet with padding -> haproxy=20 -> pfSense WAN (GBit) <--- here we can see the 00 00 bytes in the outgoing frame -> some internet hops -> client -> resulting in a defect download We wanted to reduce this to a minimal number of components. We were able to reproduce the error situation from local pfsense command li= ne (not touching the WAN interface or haproxy at all), with a "fetch http:....= .." call. So even the local file was defect which was produced on the firewall. This means that some code internally did forward the 0 bytes to the logical socket which was opened by the fetch command. This can be reproduced in 1 of ~500 requests. And we always see the padded packet in the incoming data in case a corrupti= on is found. --=20 You are receiving this mail because: You are the assignee for the bug.=