Wifi issues with 0.21.0 on ESP32 (but less on ESP32S3)

[yanshay]

Due to issues I had with esp-wifi in previous releases I'm testing it with 0.21.0 released a couple of days ago.
I'm testing with wifi_embassy_dhcp example.

What I see:

1. With ESP32 (two different boards) I almost never get an IP (no matter how much time I wait). I'd say out of 50 runs (probably more), twice it managed to get the IP. At least one of those times was after it failed to connect to wifi and retried.
2. With ESP32S3 it gets an IP pretty quickly so far, appears to be faster than with 0.20.1 but still need more time to tell. What I think I've seen though that it fails to connect to wifi, then retried and succeeds quite  few times. I almost never saw that with previous release 0.20.1 .

All boards connect to the same SSID with same credentials and on the same router. And esp32 devices both previously worked fine with wifi. So difference in behavior is highly likely due to software.

(another point I can mention with previous release 0.20.1 - with ESP32S3 I have many cases where the board gets to a period when it can't get an IP. In those cases I noticed that if it fails to connect to wifi and then retried and succeed then it suddenly is able to get the IP, as if that failure made things work).

Any logs I can turn on on the ESP32 to troubleshoot the 'not receiving IP' issue? It's a pretty big issue for me not being able to rely on the device to get connected properly.

[AnthonyGrondin]

If you have wireshark installed, you can use the following extension: esp-wifishark and build esp-wifi with the feature dump-packets to see your packets in Wireshark.

[bjoernQ]

The biggest change is we are using updated drivers now. To verify they are not causing issues you could checkout esp-idf rev. c8fc5f643b7a7b0d3b182d3df610844e3dc9bd74 and run the https://github.com/espressif/esp-idf/tree/master/examples/wifi/getting_started/station example (but I don't think the updated drivers cause an issue)

Second thing that was changed is we are using slightly different defaults now - you could override the new defaults with the old values.
See
https://github.com/espressif/esp-idf/tree/master/examples/wifi/getting_started/station
https://github.com/espressif/esp-idf/tree/master/examples/wifi/getting_started/station

[AnthonyGrondin]

Considering the fact that sometimes the DHCP server can take a long time and many DHCP Discover requests, I wonder if those packets are actually broadcasted on the line. We see them in the wireshark log, but can we confirm that the DHCP server sees those broadcasted packets?

Another thing I notice is that transaction IDs don't seem the match the DHCP spec.

For example, in the logs where it takes a long time, the client (esp32 / smoltcp) sends a DHCP Request with a new ID instead of reusing the original session ID.

[yanshay]

The way I interepret these logs (though I'm not sure I know to interpret them correctly), is that rows with 0.0.0.0. are sent. by the device and 192.168.10.1 are sent by the DHCP server (this is for. sure the address of the DHCP server).

So first row in the view is the device sending a request (and setting the id).
Second row the server responds with an offer (after a bit over a second).
The device ignores that offer (or maybe has some issues processing it) and within 200ms sends a new request with a new ID (what you colored). So the two rows you marked are not the same transation and it's initiated by the device, not by the server.

Is my reading of the logs correct?

[AnthonyGrondin]

DHCP Request is a response to a DHCP Offer request. I believe according to RFC 2131 it should match the ID from DHCP Offer and DHCP Discover.

I also notice that requests always start with the same IDs; 0x07ef3bd9 followed by 0xdc41ec2e. This indicates that the same seed is reused across reboots for smoltcp. Can you ensure that you use a randomly generated seed when you initialize the embassy-net / smoltcp stack.

[yanshay]

DHCP Request is a response to a DHCP Offer request. I believe according to RFC 2131 it should match the ID from DHCP Offer and DHCP Discover.

Ok, so that's still an issue with the device issued message, right?
It also responds with many request while there is only one Offer message, and it does that every 5 seconds.

So I read now that in response to the Request the DHCP server is supposed to send an Ack, and this doesn't show in the logs until the end.
So if the request came out with an incorrect ID that would explain why the server doesn't respond.

But... at the end of the session Ack was sent, even though there the transaction-id is also not the same as the offer yet it still work.
So I think it has to do with something else inside the request packet that the dhcp server decides to ignore and not respond to.
I just wonder why it work with a single Access Point for the SSID. and it doesn't when there are several. serving. that SSID.

I also notice that requests always start with the same IDs; 0x07ef3bd9 followed by 0xdc41ec2e. This indicates that the same seed is reused across reboots for smoltcp. Can you ensure that you use a randomly generated seed when you initialize the embassy-net / smoltcp stack.

I'm using the same as the wifi examples, so not a random seed.
Is there an example of the proper way to generate a random seed?
But could that be the reason as to why it doesn't work when several access points are working while working perfectly well (and for quite some time now) when only a single access point is available for the SSID?

[AnthonyGrondin]

You can use the RNG peripheral before passing it to esp-wifi to generate a random seed:

let rng = Rng::new(peripherals.RNG);

let lower = rng.random() as u64;
let upper = rng.random() as u64;
let seed = upper << 32 | lower;

// Init network stack
let stack = &*mk_static!(
    Stack<WifiDevice<'_, WifiStaDevice>>,
    Stack::new(
        wifi_interface,
        config,
        mk_static!(StackResources<3>, StackResources::<3>::new()),
        seed
    )
);