> On Jul 10, 2022, at 6:10 PM, Rick Macklem <rmacklem@xxxxxxxxxxx> wrote: > > Hi, > > I have been trying to improve the behaviour of the FreeBSD > NFSv4.1/4.2 client when using the "intr" mount option. > > I have come up with the following scheme: > - When RPCs are interrupted, mark the session slot as potentially bad. > - When all session slots are marked potentially bad, do a > DestroySession (only op in RPC) to destroy the session. > - When the server replies NFS4ERR_BAD_SESSION, > do a CreateSession (only op in RPC) to acquire a new session and > continue on. > > When testing against a Linux 5.15 server, the CreateSession > succeeds, but returns the same sessionid as the old session. > Then all subsequent RPCs get the NFS4ERR_BAD_SESSION reply. > (The client repeatedly does CreateSession RPCs that reply NFS_OK, > but always with the same sessionid as the destroyed one.) > > Here's what I see in the packet trace: > (everything works normally until all session slots are marked > potentially bad at packet# 14216) > packet# RPC > 14216 DestroySession request for sessionid 2725cb62002ed418040...0 > 14302 DestroySession reply NFS_OK > 14304 Getattr request (using above sessionid) > 14305 Getattr reply NFS4ERR_BAD_SESSION > 14306 CreateSession request > *** Now here is where I see a problem... > 14307 CreateSession reply NFS_OK with sessionid > 2725cb62002ed418040...0 (same as above) > 14308 Getattr request (using above sessionid) > 14309 Getattr reply NFS4ERR_BAD_SESSION > - and then this just repeats... > The whole packet trace can be found here, in case you are interested: > https://people.freebsd.org/~rmacklem/linux.pcap > > It seems to me that a successful CreateSession should always return > a new unique sessionid? Hi Rick, thanks for the bug report. CREATE_SESSION has a built-in reply cache to thwart replay attacks. It can legitimately return the same sessionid as a previous request. Granted, DESTROY_SESSION is supposed to wipe that reply cache... I'd like to see if there's a test in pynfs that replicates or is close to the series of operations in your trace so that I can reproduce on my lab systems and watch it fail up close. -- Chuck Lever
