Date: Tue, 12 Nov 2019 21:32:19 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235607] Incorrect checksums with NAT on vtnet with offloading Message-ID: <bug-235607-7501-USv83Am99i@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235607-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-235607-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=3D235607 Vincenzo Maffione <vmaffione@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vmaffione@FreeBSD.org --- Comment #9 from Vincenzo Maffione <vmaffione@FreeBSD.org> --- Not 100% sure, but I think you are hitting the same problem as me. If I am not mistaken, you can reproduce a similar problem with a simpler (t= est) configuration in your fbsd_guest_fw: no layer 3 processing, but just a brid= ge0 to bridge vtnet0 and vtnet1 together, e.g.: # ifconfig bridge0 create addm vtnet0 addm vtnet1 In this scenario (with csum enabled) packets coming from vtnet0 with "incor= rect checksum" will exit vtnet1 with incorrect checksum, and will be discarded at the next hop. The root of the problem is that vtnet cannot really implement a csum offload (since there is no hw that does that), but it rather delays the TCP checksum computation hoping that someone will do that later (if necessary). Unfortunately, the FreeBSD mbuf does not have enough metadata to store and forward the metadata contained in the per-packet virtio-net header (as defi= ned in the VirtIO standard). This information is already lost when the packet arrives on vtnet1 on transmission, so that vtnet1 is not asked to do the offloads (CSUM_TCP is not set), and therefore the packet does not survive t= he next hop. See also here: https://reviews.freebsd.org/D21315 About your setup: I see that you have offloads support on vtnet0 and vtnet1 (e.g. TXCSUM, RXCSUM, etc.) --> I guess you are not using bhyve as an hypervisor, because it does not support offloads in 12.0? I guess you are u= sing Linux QEMU/KVM with TAP interfaces backing the vtnet* devices? --=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-235607-7501-USv83Am99i>