wiznet5k_send_ethernet: fatal error -5
Port, board and/or hardware
Wiznet W5100S-EVB-Pico
MicroPython version
MicroPython v1.25.0 on 2025-04-15; W5100S-EVB-Pico with RP2040
also 1.24.1, and 1.24.0, but 1.23.0 doesn't give the error
Reproduction
MicroPython v1.25.0 on 2025-04-15; W5100S-EVB-Pico with RP2040
Type "help()" for more information.
import network
nic = network.WIZNET5K()
nic.ifconfig()
('192.168.1.137', '255.255.255.0', '192.168.1.254', '192.168.1.254')
nic.active(True)
wiznet5k_send_ethernet: fatal error -5
nic.isconnected()
True
Expected behaviour
Expected no error to be reported.
However, the error does not seem to affect the operation. The ethernet socket behaviour seems to be working ok.
Observed behaviour
wiznet5k_send_ethernet: fatal error -5
was printed out, but operation of ethernet seems to be working, however I can't be certain all functions are working correctly at this time
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
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