Describe the Problem

I'm building an application with the w5500-evb-pico. Upon setting up the SPI and initializing the registers, I used the Udp::udp_bind call to bind Sn0 to some port. However, this often blocks forever (or until the watchdog resets the chip). I've narrowed it down to

while self.sn_sr(sn)? != Ok(SocketStatus::Udp) {}

in udp_bind being the problematic loop and the reason is that the SocketStatus is Closed for some reason. This happens more often than not and I'm not sure what the issue may be here. I've tried with 2 different wiznets and both experience the same problem.

Expected Behaviour

udp_bind doesn't block.

Steps to Reproduce

Setup a w5500-evb-pico, connected over ethernet to a computer. Initialize the w5500 eh0 vdm

I can share some source code as well but it's not much different from what's here: https://github.com/newAM/w5500-issue-252/blob/main/src/main.rs, but I can try running that specifically to see if I have the same issue on that source.

Describe the Problem

Unfortunately, I cannot now reproduce the problem, the hardware is behaving perfectly. But maybe you recognize something in the description and can give advice. Otherwise feel free to close this again.

I started with the ambientsensor project and adapted it to my chip (Raspberry Pi Pico, rp2040, connected to a small W5500 breakout module). You can see the current state here: https://github.com/birkenfeld/rp2040-w5500/blob/main/src/main.rs

(As a side node, I had to add a 500 millisecond delay between link-up and starting DHCP. Otherwise the first DISCOVER would be sent fine from the firmware perspective, but Wireshark never saw it on the wire.)

From the beginning I started seeing a problem processing OFFER replies from the DHCP server, with the log saying I got "0 bytes from 64.0.0.1:0". I checked in udp_reader, in hl/src/udp.rs:770, and saw that the RSR was correct (302 bytes), but the received header data indeed was [64, 0, 0, 1, 0, 0, 0, 0]. Added some logging at that point, which seemed to make it appear more rarely, leading me to suspect a race condition. However, the garbage data was always "64.0.0.1:0".

However, now that I tried to reproduce it today, everything works flawlessly. I haven't even touched the hardware since I'm not physically there 🤷‍♂️

Anyway, any advice that might pop into your head is appreciated. And of course, MANY thanks for this excellent library. It's always a pleasure to check for Rust support of a new chip, since if a library exists, it's usually of high quality.

Logging

Log of a working session:

DEBUG RX 302 B from 192.168.0.1:67
└─ w5500_dhcp::{impl#0}::process::recv @ /home/gbrandl/devel/ext/w5500-rs/dhcp/src/fmt.rs:125

What happened before:

DEBUG RX 0 B from 64.0.0.1:0
└─ w5500_dhcp::{impl#0}::process::recv @ /home/gbrandl/devel/ext/w5500-rs/dhcp/src/fmt.rs:125

Describe the Problem

Trying to get DHCP working with my local network where the PC is running dnsmasq, I saw DISCOVER, OFFER, and REQUEST on the wire but dnsmasq wouldn't react to the latter.

After debugging a while and comparing the DHCP packets to those from other devices, the reason seems to be that this library doesn't send the ServerId option (54) in the DHCPREQUEST message. I hacked that in and got a DHCPACK. (Will make a PR soon.)

Expected Behaviour

Device gets an IP assigned.

Steps to Reproduce

Run the ambientsensor or similar example on a network with dnsmasq (here version 2.89)

Logging

Can be provided if needed.

Additional Context

There are some big changes upcoming, including an API for streaming bytes from the socket buffers (finally!).

This is a TODO list of things I want to do before the next set of releases.

• Release regsim first since those are small changes
• Run the HL testsuite with physical hardware
• Run cargo-spellcheck on the docs
• Read the HL and DHCP documentation for added / changed functions
• Add test coverage for TCP readers & writers, either by implementing MQTT with tests, or direct testing.
• Fix the hostname TODO in DHCP land, move DNS Hostname to HL?
• rg todo
• Check that handling for DNS interrupts functions similarly to DHCP & SNTP, if releasing SNTP.

Hi,

This crate looks awesome!

Just in case you did not know it existed, i wanted to share https://github.com/rust-embedded-community/embedded-nal/ as i think it could benefit the adoption of this crate over all, as it makes it drop-in replaceable with all the other crates/devices requiring embedded-nal