markj has been working to make MROUTING multi-FIB.

In D55631#1285161, @kevlo wrote:

In D55631#1284650, @bms wrote:

I was able to obtain an axge(4) compatible USB3 adapter for ~6GBP from Amazon.

Is the chipset ax88279? If so, could you send me the link to the product so
I can buy one? Thanks.

OT: I have an item to look at TCP_QUICKACK like Nagle suggested as per my DevSummit workplan

In D56115#1284434, @iyan005_outlook.com wrote:

So we've seen functions grow new errors over time, or some implementations return other errors for reasons that were consistent with the standard, but maybe not one of the ones listed.

Yeah that makes a lot of sense, best to be future proof.

+1 for doing this, but I have not reviewed code (yet).

I was able to obtain an axge(4) compatible USB3 adapter for ~6GBP from Amazon.

TL;DR Not functional under KVM passthrough of either ThinkPad P14s xHCI node.

I concur with @imp 's point.

Could use @imp eyes on this later but looks pretty straightforward.

Comments inline. +10 points for joining us on Phabricator.

Er, chaps, there is RFC 9622 to digest, the end of the BSD sockets API as we know it perhaps.

No objection to using netlink instead of sysctl for retrieving group state in principle.

In D53472#1281146, @bms wrote:

Any hints about how to expedite a loader build with this in the tree? It would require building a USB image?

In D53472#1281160, @imp wrote:

In D53472#1281146, @bms wrote:

I can point the EFI MonotonicCounter GSoC volunteer here for hints, I did not see how to pass things from loader to kernel in a more structured way being one of the older BIOS generation folk.

file_addmetadata(kfp, MODINFOMD_FW_HANDLE, sizeof(ST), &ST);

Is how it's done. You define a new MODINFOMD_xxxx and you pass it from the loader... The kernel reads with

OK, my SIIG cable arrived, and I have yet to test with it. I'll plug in via a hub for safety at first, and to test with udbc(4) as the client end (I used to use udbp(4) for this way back when), I'll need to pass through a USB device in KVM to my FreeBSD VMs, which at libvirt level requires an XML edit and restart.

We are probably fine here.

+1 vote for just doing this, all the RIBs built on top of modern FreeBSD FIB need to change with it anyway.

OT: carp(4) could do with being refactored to use HMAC from opencrypto rather than rolling its own.

In D55777#1276492, @pouria wrote:

if_epair looks suspicious. I will verify ifmedia protection on other interfaces right now.

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.

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.

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.