> Looking at the network--my server's not responding to the first data > message. I see that linux client (when doing mount -t nfs -o "vers=4.1,sec=krb") always does the same (i.e. the very 1st packet with EXCHANGE_ID operation comes with GSS sequence number=1, then CREATE_SESSION uses seq_num=2, and so on). If your server works normally with a regular mount, I don't think that my fix is not related at all to this problem volodymyr. On Fri, Oct 1, 2021 at 12:25 AM J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Thu, Sep 30, 2021 at 05:11:23PM -0400, J. Bruce Fields wrote: > > On Thu, Sep 30, 2021 at 06:22:09PM +0300, Volodymyr Khomenko wrote: > > > commit b77dc49c775756f08bdd0c6ebbe67a96f0ffe41f > > > Author: Volodymyr Khomenko <volodymyr@xxxxxxxxxxxx> > > > Date: Thu Sep 30 17:53:04 2021 +0300 > > > > > > Fixed GSSContext to start sequence numbering from 1 > > > > > > GSS sequence number 0 is usually used by NFS4 NULL request > > > during GSS context establishment (but ignored by server). > > > Client should never reuse GSS sequence number, so using > > > 0 for the next real operation (EXCHANGE_ID) is possible but > > > looks suspicious. Fixed the code so numbering for operations > > > is done from 1 to avoid confusion. > > > > 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. > > Looking at the network--my server's not responding to the first data > message. > > I think the Linux server just has a bug. I'll make a patch.... > > --b.
