Working on what I thought would be a simple re-arrangment of examples/wiznet5k_simpleserver.py to make it a little easier to use (#88 ), I think I found one or more issues.

1. I try sending the contents of this repo's code of conduct, using: nc 192.168.10.1 50007 < CODE_OF_CONDUCT.md
2. The simple server reads 1024 bytes, echoes it back
3. nc exits, which tells me that the TCP socket is closed: it knows it has nothing left to send, and I believe this indicates the server has closed their end too

Expected behavior:
Simple Server loops back and accepts another connection (per local changes in #88)

Actual behavior:
Server gets stuck inside __exit__

Connecting to the serial port on my RP2040 Feather, I can send control-c to stop the loop. The stack trace is:

Traceback (most recent call last):
  File "code.py", line 39, in <module>
  File "adafruit_wiznet5k/adafruit_wiznet5k_socket.py", line 184, in __exit__
  File "adafruit_wiznet5k/adafruit_wiznet5k_socket.py", line 207, in status
  File "adafruit_wiznet5k/adafruit_wiznet5k.py", line 666, in socket_status
  File "adafruit_wiznet5k/adafruit_wiznet5k.py", line 1126, in _read_snsr
  File "adafruit_wiznet5k/adafruit_wiznet5k.py", line 1166, in _read_socket
  File "adafruit_wiznet5k/adafruit_wiznet5k.py", line 573, in read
KeyboardInterrupt: 

I think it's stuck inside this loop waiting for the socket to transition out of FIN_WAIT:

My hypothesis is that the socket isn't being closed because there's buffered data waiting to be read, but I don't know that for sure. The simple server example code seems fragile for requests under 1024 bytes (blocks waiting for more, I think the default is 0 timeout), and I'm hitting this issue with requests >1024 bytes.

On my client machine, netstat shows sockets to the ethernet module in both FIN_WAIT_1 and CLOSING status. I think one set of those are sockets where I canceled the nc and the server never set up a socket with accept() (so a red herring), but the other group is sockets for this issue.