fibnum2 -- socket FIB inheritance from interface FIB

[vixie]

these changes are intended to support multihoming using per-interface FIBs in two new ways:

1. for TCP accept(), if the listener socket has FIB zero (0) meaning "unset", but the input interface has a non-zero FIB meaning "set", the created socket will have the interface's FIB rather than the listener socket's FIB. (still outstanding: SCTP support.)

2. for connect(), sendto(), and sendmsg(), the FIB of the output interface (which can be zero (0) meaning "unset") will be used to select the routing table used for the TCP SYN or other packet (UDP) to be transmitted. (still outstanding: SCTP support.)

the intent is to allow operations/management interfaces to have a default route that differs from production/service interfaces, because when you need the former, it's often because you can't use the latter. it also makes multi-provider multihoming symmetric, so that TCP sessions and UDP transactions can send each response to the same upstream router who delivered the request. whenever end to end path times are a lot larger than congestion-related jitter, forward/backward path symmetry becomes important. finally, wherever firewall policies including uRPF exist, it's a great idea to send response packets via the interface whose address will be that packet's source.

future work will include teaching sshd to setfib() after fork() to the FIB of the interface whose address is the destination address of the TCP SYN, in order that "netstat -rn" give correct results and other shell commands will share fate with the control connection.

[github-actions]

Thank you for taking the time to contribute to FreeBSD!
There is an issue that needs to be fixed:

• Missing Signed-off-by lines^{d675d82, 73c8d93, d35501a}

[markjdb]

We should document this new behaviour in the accept.2 man page (which sadly makes no mention of FIBs today). Let me know if you'd like help with that.

[markjdb]

For what it's worth, your latest push didn't change any code, you just pushed a merge with the main branch. Also note that there is a new solisten_clone() call in uipc_usrreq.c which needs to be updated to set the FIB of the nascent socket to 0 (since AF_LOCAL sockets don't belong to any FIB).

Also please avoid pushing merge commits: github PRs should consist of a series of commits on top of recent main. From CONTRIBUTING.md: "When updating your pull request, please rebase with a forced push rather than a merge commit."

[vixie]

On Sunday, May 25, 2025 3:10:31 PM UTC Mark Johnston wrote: markjdb left a comment (freebsd/freebsd-src#1693) For what it's worth, your latest push didn't change any code, you just pushed a merge with the `main` branch. Also note that there is a new solisten_clone() call in uipc_usrreq.c which needs to be updated to set the FIB of the nascent socket to 0 (since AF_LOCAL sockets don't belong to any FIB). Also please avoid pushing merge commits: github PRs should consist of a series of commits on top of recent `main`. From CONTRIBUTING.md: "When updating your pull request, please rebase with a forced push rather than a merge commit."

my rebase of my freebsd-src fork has somehow bolluxed my fork which now shows upstream commits like "index ebba0ccd9f5..60010da6ad5" as if they were part of my local fibnum2 branch in need of me to commit them. what i need to do is start over in a new pull request after i get it compiling again and with all current PR comments including the robot's and yours addressed. stand by.

…

-- Paul Vixie

[vixie]

since i couldn't save the branch after my rebase failure, this PR is closed, and will reopen as "fibnum3".