Definitely an improvement. Thank you.

Looks good. I'll commit it and create a pull request to our upstream hostap.

Agree with glebius.

Otherwise it looks good. This has the advantage of:

OK. I figured this was intentional.

Looks good. But I suggest holding off committing this until Juergen or Harlan sign off on this. They're the people who asked for it. They're trying to work around issues where VMware VMs are starved of resources and ntp needs to make big adjustments to catch up the clock after a VM has not executed for a number of seconds or minutes.

Looks good.

I started a new thread with the participants of the original email thread and added kib@ to it. Waiting for their replies.

I expect Harlan Stenn and Juergen Perlinger to be satisfied with this. I'll check in with them and cc you.

nwtime.org need it to return the current time, i.e. clock_gettime() output atomically to avoid the expense of making another system call. Adding a clock_id satisfies one of the two requirements. I suppose current time could be returned in *ts upon return.

In D27459#614027, @jhb wrote:

In D27459#613956, @jtl wrote:

This does not fix the regression I am experiencing in my test setup. I am testing with a machine which uses a LAGG interface to communicate with the outside world. Shutting this interface down still makes my SSH sessions hang.

My earlier diagnosis was that this is caused by the following sequence:

1. init gets the signal to shutdown.
2. init runs the shutdown scripts. The sshd shutdown script kills off the daemon, but not the forked processes to handle individual sessions. After rS366857, we shut down the network here. (And, this change still shuts down the network as part of the shutdown scripts.)
3. Only after all shutdown scripts run does init kill off the remaining processes. This is where the child sshd processes now get killed off. However, because the network is gone, the system has no way to close its TCP, SCTP, etc. sessions.

If my analysis is correct, further work is needed to allow shutting down interfaces without this regression. One path is what I proposed in D27464. Another path is to do the interface shutdown after killing off other processes (however, that seems like a relatively major change). Another path is to have the kernel shutdown any TCP/SCTP/etc. sessions when an interface is going down which would make it so the remote side of the session is no longer reachable (however, that also seems like a relatively major change). And, there are probably other alternatives, as well.

I think the third option would probably be a bad idea. As it is today, you can do things like re-dhclient and if you get the same IP, existing connections stay open (this matters when drivers do dumb things like reset for MTU or other changes which result in a link down/up cycle which resets dhclient. I think the Intel drivers have done this in the past if not still today).

I wonder if there is a better way to handle the original PRs. For example, if lagg and vlan interfaces should forward WOL requests down to the all the child interfaces. That will matter for the case where you want to use WOL to wake from suspend or low-power idle without shutting down the host.

Yes, your analysis is correct.

See https://reviews.freebsd.org/D27459.

I don't see any issues worth noting.

See https://reviews.freebsd.org/D27354 instead.

This patch is significantly smaller. The difference is icmplim could be exceeded by the modulus of the divisor whereas gnn's patch uses icmplim as an upper limit.

In D27354#612569, @rpokala wrote:

Forgive my (carefully cultivated) ignorance of the network stack, but I'd like to understand this:

1. We already have a bandwidth limit for outgoing ICMP packets
2. We already have a packets-per-second limit for outgoing ICMP packets
3. Outgoing ICMP packets which exceed either the bandwidth or packets-per-second limit are dropped and never sent
4. This change jitters the packets-per-second limit

Is that correct?

Use git diff -U99999 instead of git diff to create this patch. No functional change.

Thank you Matt. I will MFV a new tarball next time.

The upstream commit: