> On 18. Mar 2021, at 21:55, Rick Macklem <rmack...@uoguelph.ca> wrote:
>
> Michael Tuexen wrote:
>>> On 18. Mar 2021, at 13:42, Scheffenegger, Richard
>>> <richard.scheffeneg...@netapp.com> wrote:
>>>
>>>>> Output from the NFS Client when the issue occurs # netstat -an | grep
>>>>> NFS.Server.IP.X
>>>>> tcp 0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049
>>>>> FIN_WAIT2
>>>> I'm no TCP guy. Hopefully others might know why the client would be stuck
>>>> in FIN_WAIT2 (I vaguely recall this means it is waiting for a fin/ack, but
>>>> could be wrong?)
>>>
>>> When the client is in Fin-Wait2 this is the state you end up when the
>>> Client side actively close() the tcp session, and then the server also
>>> ACKed the FIN.
> Jason noted:
>
>> When the issue occurs, this is what I see on the NFS Server.
>> tcp4 0 0 NFS.Server.IP.X.2049 NFS.Client.IP.X.51550
>> CLOSE_WAIT
>>
>> which corresponds to the state on the client side. The server received the
>> FIN
>> from the client and acked it.
>> The server is waiting for a close call to happen.
>> So the question is: Is the server also closing the connection?
> Did you mean to say "client closing the connection here?"
Yes.
>
> The server should call soclose() { it never calls soshutdown() } when
> soreceive(with MSG_WAIT) returns 0 bytes or an error that indicates
> the socket is broken.
> --> The soreceive() call is triggered by an upcall for the rcv side of the
> socket.
> So, are you saying the FreeBSD NFS server did not call soclose() for this
> case?
Yes. If the state at the server side is CLOSE_WAIT, no close call has happened
yet.
The FIN from the client was received, it was ACKED, but no close() call
(or shutdown(..., SHUT_WR) or shutdown(..., SHUT_RDWR)) was issued. Therefore,
no FIN was sent and the client should be in the FINWAIT-2 state. This was also
reported. So the reported states are consistent.
Best regards
Michael
>
> rick
>
> Best regards
> Michael
>> This will last for ~2 min or so, but is asynchronous. However, the same
>> 4-tuple can not be reused during this time.
>>
>> With other words, from the socket / TCP, a properly executed active close()
>> will end up in this state. (If the other side initiated the close, a passive
>> close, will not end in this state)
>>
>>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
