wanna solve the Linux NFSv4 client puzzle?

[Rick Macklem]

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