Date: Wed, 05 Aug 2026 14:04:25 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 193246] Bug in IPv6 multicast join(), uncovered by Jenkins Message-ID: <bug-193246-7501-n9dWr2ZT3h@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-193246-7501@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193246 --- Comment #31 from Bruce M Simpson <bms@FreeBSD.org> --- That's going to be a tad harder for me to track down. I'll try to spare cycles for this, we need to get it killed off because the issue is over a decade old now, but there is other stuff to land, and other FreeBSD related projects I must instigate. Java is enough to obscure some of what's going on. truss doesn't really report much that is useful in relation to setsockopt(), and ktrace will show the call, but not the sockopt. And of course that gets further obfuscated by the fact that the need to support this forces a sockopt to be mutated in-kernel post-facto. I'm "on the hook" so to speak for the Kyua test Gleb wanted, the mtest extension will exercise the path manually, so please do try with that, as it's unclear from this output exactly which syscall returned EINVAL. The mtest code is about as simple as one can get. I seem to remember syncthing had issues in this area It is probably expecting too much for the conceptual originator of the change to come forward and upstream that which could have been upstreamed over a decade ago when I was busy with other more pressing matters. It is also disappointing that the JDK backed out the very code preceding the introduction of a "de facto" vs "de jure" feature that the IETF never ratified which would have supported FreeBSD's discrete IPv4/IPv6 stacks in its prior form. -- You are receiving this mail because: You are on the CC list for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-193246-7501-n9dWr2ZT3h>