Date: Wed, 06 Nov 2019 13:51:05 +0000
From: bugzilla-noreply@freebsd.org
To: testing@freebsd.org
Subject: [Bug 239380] sys.netpfil.pf.forward.{v4,v6} and sys.netpfil.pf.set_tos.v4 fail on i386
Message-ID: <bug-239380-32464-QdV48O5qhw@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-239380-32464@https.bugs.freebsd.org/bugzilla/>
References: <bug-239380-32464@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=3D239380 --- Comment #18 from Bjoern A. Zeeb <bz@FreeBSD.org> --- (In reply to Bjoern A. Zeeb from comment #17) As a follow-up. The problem for the test cases was as follows (at least for the IPv6 ones). To resolve the neighbour's address, scapy sends a NS. The kernel of the destination/next hop replies with a NA. Scapy receives the packets but due to the wrong offsets within the bpf head= er the frame sizes are all way off and way too large. As a result there is no result packet to the internal AsyncSniffer and neit= her the original packet nor the NA reply is seen. With the failed address resolution scapy uses a broadcast Ethernet destinat= ion MAC address on the ethernet packets. FreeBSD will mark this packet with M_BCAST as a result and higher up in the kernel certain functions will check for that and get an invalid result (or not accept the packet, or not trigger and ICMPv6 reply). With that the expected reply packet from the test cases are missing and the sniffer there will not see any further packets and either timeout or checks will fail and with that the test times out or fails. Hope that explains some of this. --=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-239380-32464-QdV48O5qhw>