> On Nov 10, 2023, at 11:10 AM, schm...@netbsd.org <schm...@netbsd.org> wrote:
>
> tcpdump of "ls" after the problem has manifested:
> https://netbsd.schmonz.com/tmp/nfs/ls-after-the-problem-tcpdump.txt
The tcpdump shows:
16:16:35.683996 IP 10.0.2.2.shilp > 10.0.2.15.exp2: Flags [P.], seq 1573:1693,
ack 1508, win 65535, length 120: NFS reply xid 834502658 reply ok 116 readdir
ERROR: READDIR/READDIRPLUS cookie is stale
Looking at the code that issues READDIRPLUS in the kernel in
nfs_readdirplusrpc():
if (nmp->nm_iflag & NFSMNT_SWAPCOOKIE) {
txdr_swapcookie3(uiop->uio_offset, tl);
} else {
txdr_cookie3(uiop->uio_offset, tl);
}
tl += 2;
*tl++ = dnp->n_cookieverf.nfsuquad[0];
*tl++ = dnp->n_cookieverf.nfsuquad[1];
*tl++ = txdr_unsigned(nmp->nm_readdirsize);
I think the cookie verifier is wrong. See:
https://www.rfc-editor.org/rfc/rfc1813#page-81
cookieverf
This should be set to 0 on the first request to read a
directory. On subsequent requests, it should be a
cookieverf as returned by the server. The cookieverf
must match that returned by the READDIRPLUS call in
which the cookie was acquired.
Probably what’s going on is that the server is verifying the directory cookie
more strictly than before. Those two lines that pack the cookieverf should be
inserting 0s if uno_offset is 0.
-- thorpej
