Date: Mon, 30 Jul 2018 02:58:12 +0000 From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 225536] ipfw tcp-setmss doesn't seems to work Message-ID: <bug-225536-8303-OIPXdnigPm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-225536-8303@https.bugs.freebsd.org/bugzilla/> References: <bug-225536-8303@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=3D225536 --- Comment #8 from John Zielinski <avernar@gmail.com> --- The incorrect network order byte compare on a little endian processor expla= ins exactly what Emmanuel is seeing. An mss of 8960 (0x0023 network order) which is compared <=3D to the desired= mss of 1460 (0xB405 network order) will be true and break out before setting the mss. The test value of 1400 (0x7805 network order) will also break out. In the case where the locally generated traffic worked with the 1400 rule I suspect the mss was 1460 already. So 1460 (0xB405 network order) <=3D 1400 (0x7805 network order) is false, since we're comparing the network order values, we don't break and go on to set the mss in the packet. People using it for the usual PPPoE clamp would normally not notice on norm= al 1460 mss packets. The 1460 (0xB405 network order) <=3D 1452 (0xAC05 netwo= rk order) test would be false and the mss would be changed. Any device using = an mss less than 1460 might have its mss increased. This bug also affects me as I also use MTU 9000 (mss 8960) on my internal network. After I applied my patch and reloaded the kernel module it started working and setting the mss properly. --=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-225536-8303-OIPXdnigPm>