Date: Sun, 25 Aug 2024 18:32:45 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute) Message-ID: <bug-280701-7501-FDwdTFP4QV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-280701-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-280701-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=3D280701 --- Comment #57 from Franco Fichtner <franco@opnsense.org> --- In closing I'd like to add a few things. It was made known that a proper bug report and steps to reproduce should be raised. I think that's only fair. This, however, requires the undesired behaviour to follow established rules which do not readily apply here. The core of the problem as we as OPNsense see it is that pf state tracking = was added to several ICMPv6 types that were not there before -- first and forem= ost ND_NEIGHBOR_SOLICIT/ND_NEIGHBOR_ADVERT. It can be said that the state trac= king is insufficient now in at least these two types of ICMPv6 communication whi= ch results in intermittent package drops. This also results in easily visible ping drops as neighbour discovery fails intermittently. The full scope of = this change is highly speculative and it has been hinted at in OPNsense and Open= BSD that further issues exist with other ICMPv6 types contained within this cha= nge. The way forward in FreeBSD releases now should be treated with the appropr= iate amount of foresight. If you want to ask for easily reproducible steps please also ask how easily reliable tests could have been added for this. Testing all of this is very difficult as I'm sure we all know now. I think we are all here to help avo= id and remedy problems together. It's not my place to question why adding state tracking to pf/ICMPv6 was a = good idea to everyone involved in bringing this to all FreeBSD releases immediat= ely so far. Someone should ask that question internally probably. A better ta= rget for this would be FreeBSD 15.0 in my very humble opinion. It would be beneficial now to have a real IPv6 expert inspect these state tracking attempts because I think so far that hasn't happened. OPNsense do= es a lot of IPv6 and does it quite well, but we are in now way experts. My first reaction to seeing the ICMP patches on stable/14 was to ignore them, but th= at was made impossible by pushing them to SA state in the way they were. Also to remind everyone what downstream does: we are trying to run projects based on FreeBSD and we mostly build integration for other software. Ideal= ly we do this on unmodified FreeBSD. Yet upstreaming patches is increasingly difficult and hostile. Our kernels only diverge because of: (1) Too strict errata policy on FreeBSD releases, and (2) upstreaming patches and stable turnaround times are too long. This causes friction with committers because they don't trust us or our capabilities or reports and think things like kernel patches are our own problems. All of it only leads to more divergence. I think that should be said here once for emphasis. And as a personal matter we should stop with the idea of "conspiracy theorising" and "downstream is broken". This will not advance FreeBSD in t= he way that it should. As far as this discussion goes I think FreeBSD has all the information that= it needs to progress this. As downstream we certainly will make a move based = on what we found out so far, too. Good luck. Cheers, Franco --=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-280701-7501-FDwdTFP4QV>