LGTM. I am not overly familiar with DAD though but it got touched during the MLDv2 import due to its wide use of solicited-node multicast addresses.

LGTM

https://sourcegraph.com/r/github.com/NetBSD/src@fa6492c255d21e5cf54f55623aa7146c0652e1dd/-/blob/sys/netinet/ip6.h?L121:8-121:22
https://sourcegraph.com/r/github.com/openbsd/src@773346f9ab1e2d6d0bef5b5f2019c0df58d4ed68/-/blob/sys/netinet/ip6.h?L116:8-116:22
https://github.com/freebsd/freebsd-legacy/commit/3e306683756b8ad0f110d8c3318a914ccd9d9006

Any plans to add stateless offload support as has been done by @np for vxlan(4) ?

@ae: Do I have you confused with @ache ? It appears I do.

In D55545#1271210, @bms wrote:

There is very little left to roll custom wrappers for in PCS at the moment in its pcap_ex.c file; most of it can now be merged to the pcap.pyx Cython file natively...

In D55545#1270945, @bms wrote:

If you're dealing with tcpdump as well, vendorizing ILNP support would be very useful to @rgrimes and myself, if you can spare the cycles.

In D55545#1270947, @glebius wrote:

I don't feel myself expert enough to neither endorse or veto the update. In general I am of course in favor of being up to date with this library.

My changes related to new BPF ioctls and obsoleting USB-ifnet were fully upstreamed and followup fixes upstream were brought back to our tree. There should be no difference to upstream left.

Just my 2c: I think we should be discouraging users from implementing CARP at all. The political history of CARP is contentious because of the patent rights Cisco had around VRRP which caused the OpenBSD developers to implement CARP in the first place. Tony Li was willing to work from within Cisco to ensure the patent was freely licensed to the OpenBSD guys, but they were not willing to work with him, so we got two protocols which collide when used on the same LAN segment. These days the patents surrounding VRRP have either expired or been once again freely granted, to the best of my knowledge, and as @olivier is probably well aware. There are also technical reasons for choosing one over the other (mostly to do with broadcast vs multicast), and CARP wound up being a garden rake on the floor when I was merging IGMPv3 and MLDv2 back in the late 00s. So it is no wonder projects like HAProxy have chosen to go the VRRP route.

Vendorizing ILNP support would be very useful to @rgrimes and myself, if you can spare the cycles.

What a coincidence, I am resurrecting a major consumer of libpcap.

TL;DR I concur with removal.

I am fond of Ivan Pepelnjak's use of the term "lemming run". I am tracking VXLAN as it was called out in my PhD Ch7 as a means of extending the architecture I proposed there to distributed sites.

Full disclosure: I was the maintainer of vendorized import of routed in FreeBSD for many years, and loosely touched the xorp_rip/xorp_ripng routing processes during tenure at ICSI and XORP, Inc.

This looks like a reasonable jumping-off point for implementing IGMP/MLD snooping in if_bridge(4) as a JKH exercise.

In D55454#1268412, @rrs wrote:

I dislike the term "hallucinated" since no, this is not a hallucination it is the AI LLM failing to read/interpret and build correct code. It's why AI is currently inferior. If I were
to write a bunch of code assuming that something existed because I did not bother to look at what I was writing to you would call that poor developer skills as
well as poor coding skills. With AI we say it "hallucinated", which is a crock, it just showed us its a poor developer with poor coding skills :-o

In D55454#1268409, @tuexen wrote:

How would you handle the assoc_id for one-to-many style sockets? Also provide that in sockstat? How did it handle the fact that most IPPROTO_SCTP-level socket options have a struct as the option value?

OT: I just scheduled an Amazon.co.uk return of an RK3399 based system, because the seller didn't provide the required accessories (case, PSU, MicroSD boot media, and HDMI-C cabling). What I actually wanted/needed was a BeagleBone Black, as IEEE 1588 is what I'm turning up...

Any plans to add gencnt to SCTP sockets?

In D55410#1267939, @timo.voelker_fh-muenster.de wrote:

I agree on @pouria's comment.

A __predict_false makes sense in the IPv6 case as well.

There seems to be significant demand from the user base for this "feature", probably because the OpenJDK is the main consumer of it, and it is doing something in-kernel that the OpenJDK socket shims handled themselves historically anyway.

In D55031#1266797, @rgrimes wrote:

Please check that this compiles properly with possible combinations INET, INET6, INET & INET6. It looks to be as if your using INET to protect INET6 only code.

Um, probably wrong on that, as these files well not be pulled in unless compiling INET6

Something smells off to me about in_ifprimaryaddr(), like not pre-emptively setting ifa to NULL. Sorry, distracted with all this git and git arc nonsense.

Correctly claim authorship.

Implementing source-address selection for IPv4 should be delegated to GenAI or JKH.

Rebase

Rebase

I chose in_ifprimaryaddr() because it's less typing and consistent
with in_ifhasaddr(), and moved its body after that function.

Rebase

Rebase

In D34139#1266223, @tuexen wrote:

In D34139#1266200, @bms wrote:

TCP_NODELAY is missing from the man page (15.0p3).

The man page lists only some examples. tcpsso recognizes much more socket option names...

TCP_NODELAY is missing from the man page (15.0p3).

Another area of potential overlap with RFC 6740+ ILNP identifier space management.

Heads up warning: these code paths are very likely to be touched by an ILNPv6 merge (RFC 6740 and up). @rgrimes and I need to have a chat first.

In D54603#1264940, @markj wrote:

Directly modifying the code to use atomic operations might help, so long as different CPUs aren't frequently contending to update the same counter. The per-VIF counters would probably be better-served by being converted to counter(9).

Wouldn't atomics be more appropriate for higher PPS yield?

Been spring-cleaning my cluster home directory, as I only regained access for the first time in nearly 10 years this morning UK time. This commit probably has some relevant history lessons.

In D13356#1263785, @cy wrote:

Send an email to my FreeBSD.org email address.

In D55267#1264064, @pouria wrote:

I'm working on refactoring union nd_opts.
The current data structure doesn't scale well with new options.
Considering the type number of ILNPv6 Locator Update Message, we would end up with a BIG data structure. For example:

...

@bms, I would appreciate any input/review you have on these changes.

I should also point out that in my final experiment chapter of my PhD thesis, I outlined a scheme for distributed site border router (dSBR) operation in FreeBSD, which implements a hot-standby scheme for ILNP on-path SBRs, using a dedicated ilnpsync interface driver very loosely modeled on pfsync.

In my original code drop for ILNP -- which I am currently retrieving from St Andrews remotely due to catastrophic loss of my original copies of my own artefacts -- the ILCC at a site border router (SBR) learns of available network locators by listening to its own IPv6 RAs.

In D41705#1263606, @bms wrote:

The closest thing I can find is wy-z/docker-cobbler for 3.3 on GitHub; this lags behind 4 minor-minors, the current release is 3.3.7, but I will give it a try.

In D41705#1262135, @bms wrote:

...I guess I am looking for a Docker image to easily stage Cobbler on my home lab LAN now.

In D13356#1262904, @cy wrote:

Imported into my GIT repo. I will review the code and make any changes needed to get it working again.

Did this ever land? I've been away for over 7 years... I remember hacking on this in my apartment share on Shattuck & Francisco in Berkeley, 2004.

In D45404#1262412, @bms wrote:

... the under-published ILNPSync (a distributed site border router state exchange protocol somewhat patterned after pfsync(4))...

I am following this Differential closely because: following Ch6 of my PhD regarding the under-published ILNPSync (a distributed site border router state exchange protocol somewhat patterned after pfsync(4)), I want to implement a change to introduce the use of the UEFI MonotonicCounter.

In D41705#1262128, @bz wrote:

Welcome back.

I'd potentially like to extend this change to support the "cmdline" field that memdisk passes in the ACPI-like table segment, to support Cobbler PXE bootstrap. I'll raise a separate Differential at that time.

I have skin in the game for this Differential. I'm happy to air out changes to support cmdline for memdisk at some point for Cobbler integration -- Canonical MaaS is not fit for purpose here -- providing we get mfsBSD into the base system image build process first. Please read on.

Today I was doing a loopback test across two Mellanox ConnectX-4 LX ports on the same NIC, with a fresh 25GBE SFP+ DAC cable. This is with a fresh install of 15.0-RELEASE on a plain Samsung EVO SATA SSD, with a recycled Dell Optiplex 3020.

The IPv4 mapped behaviour is limited to ASM memberships only, and is not directly mandated by an RFC. The comments around in6u_lookup_v4mapped_mc() reflect this-- it's something that has seen wider use than one would anticipate, despite it being kind of dog stupid to do IPv4 operations on an IPv6 socket.

In D9157#1203022, @lwhsu wrote:

For more information, check D51299 and https://people.allbsd.org/~hrs/FreeBSD/udbc/