TCP socket RESET's the connection when not reading the entire read buffer
Port, board and/or hardware
W5500-EVB-Pico, Raspberry Pi Pico W
MicroPython version
MicroPython v1.24.1 on 2024-11-29; W5500-EVB-Pico with RP2040
Reproduction
When not reading the entire TCP message, micropython will RESET the connection, instead of doing a proper TCP connection teardown.
Example:
import network
from machine import SPI, Pin
import time
import asyncio
def w5x00_init():
# https://github.com/Wiznet/RP2040-HAT-MicroPython/blob/main/Ethernet%20Example%20Getting%20Started%20%5BMicropython%5D.md
spi=SPI(0,2_000_000, mosi=Pin(19),miso=Pin(16),sck=Pin(18))
nic = network.WIZNET5K(spi,Pin(17),Pin(20))
nic.active(True)
nic.ifconfig('dhcp')
while not nic.isconnected():
time.sleep(1)
print(nic.regs())
print(nic.ifconfig())
async def handle_client_read_1000(r, w):
await r.read(1000)
w.write(b'HTTP/1.0 200 OK\r\nContent-Length: 2\r\nContent-Type: text/plain\r\n\r\nhi')
w.close()
await w.wait_closed()
async def server_async(handle_client):
await asyncio.start_server(handle_client, '0.0.0.0', 80)
while True:
await asyncio.sleep(1)
w5x00_init()
asyncio.run(server_async(handle_client_read_1000))
Expected behaviour
Reading parts of the TCP stream/reading the entire stream/not reading the stream should not change the behavior of writing into the stream.
When running the same code (except the network setup) in CPython it does a proper TCP connection teardown and does not send RESET.
Observed behaviour
When doing
curl 192.168.2.127
we get a TCP connection teardown after the payload has been send (FIN-ACK):
But when sending a message longer then the buffer (here 1000B) via
curl 192.168.2.127/hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
we get
I.e. it sends RESET instead of doing a proper connection teardown.
This causes various strange behaviors as seen in the original discussion.
Additional Information
See the original discussion
Code of Conduct
Yes, I agree
Reinitializing network.LAN with W5500 Causes Connection Loss Until Hard Reset
Port, board and/or hardware
esp32 port
MicroPython version
All Versions
MicroPython v1.25.0-preview.283.g11c9656fa on 2025-02-10; Generic ESP32 module with SPIRAM with ESP32
Reproduction
Issue Description:
When running the following MicroPython script on an ESP32 with a W5500 Ethernet module, the connection works correctly on the first run after powering up the board. However, if the script is executed again without a full power cycle or machine.reset(), the device loses network connectivity (cannot be pinged).
- Power on the ESP32 with the W5500 module connected.
- Run the following MicroPython script:
import network
import time
from machine import Pin, SPI, reset
rst = Pin(15, Pin.OUT)
rst.value(0)
time.sleep(0.1)
rst.value(1)
time.sleep(0.5)
spi_nic = SPI(1, baudrate=26000000, sck=Pin(18), mosi=Pin(21), miso=Pin(19))
nic = network.LAN(phy_type=network.PHY_W5500, spi=spi_nic, phy_addr=1, cs=Pin(5), int=Pin(4))
config = ('192.168.1.120', '255.255.255.0', '192.168.1.1', '8.8.8.8')
nic.ifconfig(config)
nic.config(mac=b'\x02\xAB\xCD\xEF\x01\x02')
nic.active(True)
time.sleep(0.5)
while not nic.isconnected():
print(".", end="")
time.sleep(0.25)
print("\r\nip=", nic.ifconfig())
- Confirm that the device is reachable via ping.
- Run the script again without resetting the board.
- Observe that the device no longer responds to ping, and the network connection is lost.
- If machine.reset() is executed before re-running the script, the connection works fine again.
Expected behaviour
Re-running the script should properly reset the W5500 and establish a new network connection without requiring a full board reset.
Observed behaviour
After executing the script multiple times without a full reset, the ESP32 loses network connectivity. The W5500 module does not seem to reinitialize correctly unless a full machine.reset() is performed.
Additional Information
Workarounds Tried:
Explicitly deactivating nic before reinitializing:
try:
nic.active(False)
del nic
except:
pass
→ Did not solve the issue.
Resetting the W5500 before reinitialization using rst pin:
→ No effect; issue persists.
Performing machine.reset() before re-running the script:
→ Works, but not an ideal solution
Code of Conduct
Yes, I agree