> The seq_num field can start at any value below MAXSEQ Yes, that's the statement I haven't found before in RFC... Probably we also need to write a test starting the seq_num from a big value (more than SEQUENCE_WINDOW) to make sure that it is really implemented properly without 'is_inited' flag (so what's the initial value?). However I still propose to keep the default behaviour of pynfs to be the same as for linux NFS4 client. I think the caller can change it when needed (to 0 or whatever needed), but the default value should be good... volodymyr. On Fri, Oct 1, 2021 at 5:13 PM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Fri, Oct 01, 2021 at 09:49:50AM +0300, Volodymyr Khomenko wrote: > > > So, I can verify that --security=krb5 works after this patch but not > > > before, good. But why is that? As you say, the server is supposed to > > > ignore the sequence number on context creation requests. And 0 is valid > > > sequence number as far as I know. > > > > By design of RPCGSS we have a 'last seen seq_number' counter on the > > server side per each GSS context > > and we must not accept any packet that was already seen before (we > > also have a bitmask of several last requests for this). > > This 'last seen counter' is unsigned int32 (the same as seq_num) so we > > can't just init it to -1 so next seq_num=0 will be valid. > > The most obvious implementation is to init it last_seen_seq_num to 0 > > so the very 1st packet after NFS4 NULL must be 1 to differ from last > > seen seq_number. > > Note in theory gssapi mechanisms can require multiple round trips (in > the GSS_PROC_CONTINUE_INIT case), so this wouldn't actually avoid > duplicate sequence numbers. > > In any case, the rfc is unambiguous here: "In a creation request, the > seq_num and service fields are undefined and both must be ignored by the > server." > > > A better implementation (theoretically) can set this counter to > > 'undefined' state by additional flag, but this is more > > resource-consuming > > (you need to process is_inited flag + last_seen_seq_num instead of > > just one counter). > > If the last seen seq_number is undefined during GSS initialization, > > then strictly speaking we can send ANY seq_num for the very 1st > > request after NFS4 NULL. > > Right, again, from RFC 2203, " The seq_num field can start at any value > below MAXSEQ." > > It can be implemented without the need for an is_inited flag. > > The initial sequence number of 0 really did find an actual bug in the > server, so pynfs is definitely doing its job in this case! > > --b.
