DHCP example fails to get an IP address on ESP32-C3

[TheButlah]

Hi, I tried running the DHCP example (commit a0a6b5fbcf7) on my esp32-c3-mini and it appears as though the code is racy. It fails to get an ip address, unless I do some random permutation of dump_packets, wifi_logs, and manually putting in for i in 1000 {} style loops.

I'm working with @ImUrX and he also cannot get the example working on his PCB, although his is a lolin_c3_mini v1.0.0 (which may have hardware issues with wifi, so could be a red herring).

If I use --release it works consistently.

[TheButlah]

From #84:

as mentioned in #88 we had similar problems before which were related to wrong timestamp calculations which shouldn't be the case now (unfortunately I was never able to reproduce it with any of my APs)

Important thing to know: which was the last commit which worked for you? No need to git-bisect - just a commit that works would be a good hint

@bjoernQ this was on the latest main, commit a0a6b5fbcf7, on my own board (not a lolin_c3_mini). When you say "wrong timestamp calculations which shouldn't be the case now" did you mean that this was solved in another branch?

[bjoernQ]

the fix back then was #44

just to double check: a0a6b5fbcf7 broke things for you while it was working before?

Interesting, since that commit just makes sure the USB keeps enabled 🤔

[TheButlah]

just to double check: a0a6b5fbcf7 broke things for you while it was working before?

I cant speak for how things worked in the past because I haven't really tried to get wifi working until now. I can confirm that on the commit referenced in my original message, it does not work.

Which range of commits should I be testing? I can try them out tomorrow and get back to you.

[bjoernQ]

That would be great!

Probably it won't work between 69956d4 and a0a6b5fbcf7 for you since you are not using the internal USB

So maybe it would already be interesting if 7bd248777dfefc4891a9dc9fc92f4fad0ac26218 works for you - unfortunately there were many, many changes after that

Probably I should try harder finding an AP that shows the same behavior here

[TheButlah]

My router is an Asus RT-AX92U btw.

[ImUrX]

I'm using fortigate with latest firmware

[TheButlah]

Just tested latest commit fe6fcfd in debug mode. It worked the first time I tried it, after that it didn't work anymore.

Commands:
    CTRL+R    Reset chip
    CTRL+C    Exit

ESP-ROM:esp32c3-api1-20210207
Build:Feb  7 2021
rst:0x15 (USB_UART_CHIP_RESET),boot:0xc (SPI_FAST_FLASH_BOOT)
Saved PC:0x4004c518
SPIWP:0xee
mode:DIO, clock div:1
load:0x3fcd5820,len:0x16ec
load:0x403cc710,len:0x95c
load:0x403ce710,len:0x2dc0
SHA-256 comparison failed:
Calculated: 25af9e3d109d88d02c90be5fb57af4df4234571b6f90ea288a6f8f2da8742ea7     
Expected: 9fafed52ab0387e903bde368d0d6bfffe0dcc3d2f90dca069a4db891108c387c       
Attempting to boot anyway...
entry 0x403cc710
I (43) boot: ESP-IDF v5.0-beta1-764-gdbcf640261 2nd stage bootloader
I (43) boot: compile time 11:30:26
I (43) boot: chip revision: V003
I (46) boot.esp32c3: SPI Speed      : 80MHz
I (51) boot.esp32c3: SPI Mode       : DIO
I (56) boot.esp32c3: SPI Flash Size : 4MB
I (61) boot: Enabling RNG early entropy source...
I (66) boot: Partition Table:
I (70) boot: ## Label            Usage          Type ST Offset   Length
I (77) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (84) boot:  1 phy_init         RF data          01 01 0000f000 00001000        
I (92) boot:  2 factory          factory app      00 00 00010000 003f0000        
I (99) boot: End of partition table
I (103) boot_comm: chip revision: 3, min. application chip revision: 0
I (111) esp_image: segment 0: paddr=00010020 vaddr=3c0c0020 size=1a5e0h (108000) 
map
I (136) esp_image: segment 1: paddr=0002a608 vaddr=3fc83848 size=01a80h (  6784) 
load
I (138) esp_image: segment 2: paddr=0002c090 vaddr=40380000 size=03844h ( 14404) 
load
I (145) esp_image: segment 3: paddr=0002f8dc vaddr=00000000 size=0073ch (  1852) 
I (151) esp_image: segment 4: paddr=00030020 vaddr=42000020 size=ba608h (763400) 
map
I (282) boot: Loaded app from partition at offset 0x10000
I (282) boot: Disabling RNG early entropy source...
is wifi started: Ok(true)
Start Wifi Scan
AccessPointInfo { ssid: "Redacted", bssid: [Redacted], channe
l: 3, secondary_channel: None, signal_strength: -28, protocols: EnumSet(), auth_m
ethod: WPA2Personal }
... redacted
Call wifi_connect
wifi_set_configuration returned Ok(())
Ok(EnumSet(Client))
wifi_connect Ok(())
Wait to get connected
Ok(true)
Wait to get an ip address

Running with --release works however.

[TheButlah]

Commit 7bd248777dfefc4891a9dc9fc92f4fad0ac26218 worked first time in debug, then never again. Same place that it hangs on: "wait to get an ip address". Running with --release works.

So its the same story regardless of which of the three commits I tried. Debug mode fails (95 percent of the time), --release works

[TheButlah]

Tested commit 3f9df3956722b00a69401e2624952438345be116. Same thing.

[bjoernQ]

Thanks for all the effort!

So, the bottom line is, it is useable with --release but only rarely works in development mode? That's less than ideal

For some reason I can now reproduce this (in dev mode) .... I see it tries to send a discovery request which never actually ends up in the tx-done-callback called (by the wifi driver) - however I see the interrupt fires

[bjoernQ]

I was able to get it working for me again in #90

In general dev-mode isn't really expected to work - some targets won't even get over the connect step and for BLE even basic advertising won't work

[TheButlah]

Well at least #90 aims to improve things, and the reliable workaround is to compile in release mode.

That should probably be made clear in bold letters in the README and docs.rs btw

[jessebraham]

This package hasn't been published so I'm not sure we can have anything on docs.rs 😉 The README is pretty clear that this is experimental, in-progress work already and that only certain features work.

[TheButlah]

I meant the cargo doc stuff. I know its experimental, don't worry - half of the dependencies in my firmware are using patches or forks, or aren't published to crates-io :)

I was just saying that some big bold "COMPILE WITH --release OTHERWISE IT WONT WORK" language in the README wouldn't be amiss :)

[bjoernQ]

Ok - probably the sentence "In general you should use the release profile since otherwise the performance is quite bad." isn't scary enough - will update the README in the linked pull-request

If it is able to connect or not in dev-mode (i.e. with debug-assertions) probably depends on how strict an AP is about timeouts

[bjoernQ]

I guess we can close this now after #90 is merged