Hi, I posted recently that enabling delegations should be avoided at this time, especially if your FreeBSD NFS server has Linux client mounts...
I thought some of you might be curious why, and I thought it would be more fun if you look for yourselves. To play the game, you need to download a packet capture: fetch https://people.freebsd.org/~rmacklem/twoclientdeleg.pcap and then load it into wireshark. 192.168.1.5 - FreeBSD server with all recent patches 192.168.1.6 - FedoraCore 30 (Linux 5.2 kernel) client 192.168.1.13 - FreeBSD client A few hints buried in RFC5661: - A fore channel is used for normal client->server RPCs and a back channel is used for server->client callback RPCs. - After a new TCP is created, neither the fore nor back channels are bound to the connection. - Bindings channel(s) to a connection is done by BindConnectionToSession. but an implicit binding for the fore channel is created when the first RPC request with a Sequence operation in it is sent on the new TCP connection. - A server->client callback cannot be done until the back channel is bound via BindConnectionToServer. Ok, so we are ready... - Look at packet #s 3518->3605. - What is going on here? - How long does this take? --> One more hint. Starting with #3605, things are working again. There are actually 3 other examples of this in the pack capture. Btw, one of the weirdnesses is said to be fixed in Linux 5.3 and the other in Linux 5.7, although I have not yet upgraded my kernel and tested this. Have fun with it, rick _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
