Open LeoSum8 opened 7 months ago
sle118
commented
6 months ago @LeoSum8 please do not cross post. I've reopened issue #412. To maximize your chances of being responded there, you need to follow the guidelines when posting an issue. If you don't, then it's wasted time for everyone in the end. https://github.com/sle118/squeezelite-esp32/issues/new?template=bug_report.md
You've done a good job on the current issue and this saves me a good amount of time when analyzing.
sle118
commented
6 months ago @LeoSum8 one thing I have noticed is that you have a conflicting setup:
You have defined the DAC i2c configuration correctly
"dac_config": "model=I2S,bck=26,ws=25,do=22,sda=21,scl=27,i2c=45"
This config would attempt to create a new i2c driver on the same GPIO but different port.
"i2c_config": "scl=27,sda=21,speed=400000,port=1",
Please remove it from the nvs.
Also, I have checked your logs and I suspect that your wifi issue is hardware related, or perhaps caused by something in your environment. This is revealed by the logs here
I (5561) wifi:state: init -> auth (b0)
I (5561) wifi:state: auth -> init (8a0)when the wifi driver flips from init -> auth back to auth -> init. If you are able to find what the description of code 8a0 mean, then you might get some answers.
The typical sequence of wifi should be:
I (5561) wifi:state: init -> auth (b0)
I (5561) wifi:state: auth -> assoc (0)
I (5571) wifi:state: assoc -> run (10)I doubt we can do anything for this issue in our code, so for now I'll go ahead and close the issue.
You could also check your power supply. for example do you get the same issue if you plug the wrover in a different power supply, if you disconnect it from the Louder board, etc.
sle118
commented
6 months ago I'll leave the issue open for a couple of days so you can find it easily.
LeoSum8
commented
6 months ago Hi Sébastien, sorry if my report caused additional work. I do not mean to waste anybody's time, especially not the time of people who create such great things as sqeezelite-esp32 in their spare time.
However, I am a bit confused. I did not open issue #412. It was opened only after I posted here the additional comment concerning my "ESP_ERR_NVS_KEY_TOO_LONG" find in the logs as I sincerely believed that it was related. But this comment is not visible here any more.
I will be able to do further test and debugging hopefully on Wednesday.
sle118
commented
6 months ago Not worries for the missing info. I want to help as much as possible given my availability and this means I'm not always in front of a computer where I can more easily navigate.
I deleted the "key too long" comment as it was not related to this issue and also because I reopened the other issue where you can add more details. I'm curious to understand how this might happen.
As for the current issue #410, I doubt I'll be able to help
LeoSum8
commented
6 months ago Thank you for checking my logs!
The I (5561) wifi:state: auth -> init (8a0) issue can be found on google and I will try to investigate further how that happens. I'll also watch the bahaviour on different firmwares (snapclient, euphonium) and check with and without the dock attached.
But just to get this off my chest, the incomplete issue #412 was not submitted by me but by @DamnDaniel-98. I think you thought it was me because it was submitted around the same time with the same content. I never submit with missing info! ;)
LeoSum8
commented
6 months ago So I just checked if the same behaviour occurs with another firmware (euphonium). It does, but somehow it is caught. Here is an excerpt from the boot sequence of euphonium:
D [core] Core.cpp:187: EventBus message received
I [core] Core.cpp:268: Connecting to HomeWifi
I (4509) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (4689) wifi:state: init -> auth (b0)
I (4689) wifi:state: auth -> init (8a0)
I (4699) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
E [ESP32Connectivity] ESP32Connectivity.cpp:334: WiFi connection retry, attempt #1
E [ESP32Connectivity] ESP32Connectivity.cpp:334: WiFi connection retry, attempt #2
I (9529) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (9529) wifi:state: init -> auth (b0)
I (9539) wifi:state: auth -> assoc (0)
I (9539) wifi:state: assoc -> run (10)
I (9569) wifi:connected with HomeWifi, aid = 4, channel 1, BW20, bssid = b0:f2:08:d5:f1:6f
I (9569) wifi:security: WPA2-PSK, phy: bgn, rssi: -57
I (9669) wifi:pm start, type: 1
I (9669) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (9669) wifi:AP's beacon interval = 102400 us, DTIM period = 1
I (9689) wifi:<ba-add>idx:0 (ifx:0, b0:f2:08:d5:f1:6f), tid:6, ssn:2, winSize:64
I (10689) esp_netif_handlers: sta ip: 192.168.178.36, mask: 255.255.255.0, gw: 192.168.178.1
I [ESP32Connectivity] ESP32Connectivity.cpp:312: Connected, ip addr 192.168.178.36
I (10699) mdns_networking: _mdns_pcb_init(tcpip_if=0, ip_protocol=0)
I (10699) mdns_networking: _mdns_pcb_init(tcpip_if=1, ip_protocol=0)
E (10719) mdns_networking: [sock=55] Failed to set IP_ADD_MEMBERSHIP. errno=125: Address not available
E (10729) mdns_networking: Failed to add ipv6 multicast group for protocol 0
I [ESP32Connectivity] ESP32Connectivity.cpp:99: Writing WiFi configuration to NVS storage...Thank you for checking my logs!
The
I (5561) wifi:state: auth -> init (8a0)issue can be found on google and I will try to investigate further how that happens. I'll also watch the bahaviour on different firmwares (snapclient, euphonium) and check with and without the dock attached.But just to get this off my chest, the incomplete issue #412 was not submitted by me but by @DamnDaniel-98. I think you thought it was me because it was submitted around the same time with the same content. I never submit with missing info! ;)
I do apologize for the mistake and I think you are right. I am not too close #412 anyways since I cannot reproduce.
sle118
commented
6 months ago So I just checked if the same behaviour occurs with another firmware (euphonium). It does, but somehow it is caught. Here is an excerpt from the boot sequence of euphonium:
D [core] Core.cpp:187: EventBus message received I [core] Core.cpp:268: Connecting to HomeWifi I (4509) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 I (4689) wifi:state: init -> auth (b0) I (4689) wifi:state: auth -> init (8a0) I (4699) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 E [ESP32Connectivity] ESP32Connectivity.cpp:334: WiFi connection retry, attempt #1 E [ESP32Connectivity] ESP32Connectivity.cpp:334: WiFi connection retry, attempt #2 I (9529) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1 I (9529) wifi:state: init -> auth (b0) I (9539) wifi:state: auth -> assoc (0) I (9539) wifi:state: assoc -> run (10) I (9569) wifi:connected with HomeWifi, aid = 4, channel 1, BW20, bssid = b0:f2:08:d5:f1:6f I (9569) wifi:security: WPA2-PSK, phy: bgn, rssi: -57 I (9669) wifi:pm start, type: 1 I (9669) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us I (9669) wifi:AP's beacon interval = 102400 us, DTIM period = 1 I (9689) wifi:<ba-add>idx:0 (ifx:0, b0:f2:08:d5:f1:6f), tid:6, ssn:2, winSize:64 I (10689) esp_netif_handlers: sta ip: 192.168.178.36, mask: 255.255.255.0, gw: 192.168.178.1 I [ESP32Connectivity] ESP32Connectivity.cpp:312: Connected, ip addr 192.168.178.36 I (10699) mdns_networking: _mdns_pcb_init(tcpip_if=0, ip_protocol=0) I (10699) mdns_networking: _mdns_pcb_init(tcpip_if=1, ip_protocol=0) E (10719) mdns_networking: [sock=55] Failed to set IP_ADD_MEMBERSHIP. errno=125: Address not available E (10729) mdns_networking: Failed to add ipv6 multicast group for protocol 0 I [ESP32Connectivity] ESP32Connectivity.cpp:99: Writing WiFi configuration to NVS storage...
I will see what I can do. The system could probably try a couple of times on (WIFI_REASON_AUTH_FAIL) before jumping to access point mode. I don't want to invest too much time on this version (a refactoring is in progress) but since it will improve stability of this release, it is worth the effort.
Thanks for the finding
LeoSum8
commented
6 months ago Thank you for taking the time for this edge case. A couple of retries should definitely help me.
When trying to find out what (8a0) means, as you suggested, I did find a couple of mentions. Could be a problem with the combination of certain ESP32 boards, the AVM Fritz!Box routers (very common in Germany) and signal strength.
The reason code 202 (AUTH_FAIL) is not very helpful: "Espressif-specific Wi-Fi reason code: the authentication fails, but not because of a timeout."
sle118
commented
6 months ago Thank you for taking the time for this edge case. A couple of retries should definitely help me.
When trying to find out what (8a0) means, as you suggested, I did find a couple of mentions. Could be a problem with the combination of certain ESP32 boards, the AVM Fritz!Box routers (very common in Germany) and signal strength.
The reason code 202 (AUTH_FAIL) is not very helpful: "Espressif-specific Wi-Fi reason code: the authentication fails, but not because of a timeout."
Given how other projects have delt with this, it might not be that much of an edge case
DAONEW
commented
4 months ago Hi @LeoSum8 ,
I had a very similar problem after changing my Fritz!Box to the 7530. My squeezelite-esp32 clients were disconnecting all the time. The 8a0 was shown in my logs too.
For me disabling the Package acceleration did the trick. They are not disconnecting anymore - as far as I can see. (Strangely I also had another issue changing to the new AP at all. For some other reason the squeezelite would not change the new AP even though it would successfully login. I had to reflash the firmware completely and thereby resetting the AP internal variables. Now, it accepted the new AP login.)
PS: thank you for this great project btw!
Hi all, I found some time today to retry getting squeezelite to run on my Louder ESP32. Most of the time, the first attempt to connect to my home wifi fails and squeezelite falls back to AP mode. A manual reboot via RST-Button usually results in a successfull connection. Is this a known problem with certain setups? Would it be possible to make squeezelite try connecting several times before failing to AP-Mode? I saw that with other firmwares (euphonium, snapclient) the first connection attempt to my wifi sometimes fails too, but sinc those other firmwares just retry, I usually don't notice.
I think this behaviour also explains, why I sometimes seem to "loose" the client. I haven't been able to record that yet, since I don't have it hooked up to serial all of the time, but I guess if wifi fails at a later point, it would fall back to AP-Mode too and not retry connecting, right?
Preliminary Information
Hardware Details
Please describe your hardware setup:
NVS Settings
Logs
Full Log
Trimmed Log
Issue Description