You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that exasock won't terminate nor time out sockets in FIN-WAIT-2 state exasock process is terminated in middle of receiving data from a peer leaving those sockets lingering until system is rebooted.
Here is a simple reproducible scenario using netcat:
Server side: generate large ascii file to transmit to a client base64 /dev/urandom | head -c 10000000 > file.txt
Server side: start TCP server to publish generated file to the first connected client (use of exasock is not necessary) cat file.txt - | nc -l 10.248.194.179 12345
Client side: as soon as connection is established and some data is received kill the process using Ctrl+C
Confirm sockets stuck in FIN-WAIT-2 state exasock-stat
Example:
exasock-stat
Active ExaNIC Sockets accelerated connections (servers and established):
Proto | Recv-Q | Send-Q | Local Address | Foreign Address | State
TCP | 1048396 | 0 | 10.248.194.178:49765 | 10.248.194.179:12345 | FIN-WAIT-2
TCP | 1048556 | 0 | 10.248.194.178:35827 | 10.248.194.179:12345 | FIN-WAIT-2
In addition to ports allocated and resources leaking after reviewing the code I also discovered that kernel module will keep re-evaluating those sockets indefinitely as well.
The text was updated successfully, but these errors were encountered:
It appears that exasock won't terminate nor time out sockets in
FIN-WAIT-2
state exasock process is terminated in middle of receiving data from a peer leaving those sockets lingering until system is rebooted.Here is a simple reproducible scenario using
netcat
:base64 /dev/urandom | head -c 10000000 > file.txt
exasock
is not necessary)cat file.txt - | nc -l 10.248.194.179 12345
exasock
exasock nc 10.248.194.179 12345
Ctrl+C
FIN-WAIT-2
stateexasock-stat
Example:
In addition to ports allocated and resources leaking after reviewing the code I also discovered that kernel module will keep re-evaluating those sockets indefinitely as well.
The text was updated successfully, but these errors were encountered: