Date: Fri, 17 Mar 2023 13:18:37 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 270285] Network issue with very small frames (tcp, padded) Message-ID: <bug-270285-7501-f6laLdyVMa@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-270285-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-270285-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270285 --- Comment #2 from Marcus Haarmann <mhaarmann@midoco.de> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270285-7501-f6laLdyVMa>