-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1.0.3 lost ability to connect to an access point; v1.0.2 works #3225
Comments
@ssilverman do you have any logs to show why it failed? I can't reproduce this issue with any of my testing, nor can a lot of others who have also tested 1.0.3. |
I just tried these steps:
I'm using the exact same code between a v1.0.2 test and a v1.0.3 test. The only difference is that the dots keep printing forever with v1.0.3 and this is printed once when I add "Info" debugging: |
I just turned on the "Debug" level and I get this:
... and dots forevermore... |
Turn on the highest verbosity of the log level and rerun your test. Use the ESP32 DevKit-C board type (base board type), there is no meaningful difference for the SparkFun/Adafruit boards for this test. The 4WAY_HANDSHAKE_TIMEOUT indicates that the esp32 is not able to complete the connection process and there may be additional details in the more verbose logs. |
I turned on the "Verbose" level and now it works. Changing back to the less verbose debug levels doesn't change now; it works. It didn't start working until I turned on this logging level, and now I can't get it to fail. This is the first time I've seen it work since I installed v1.0.3 (yesterday and lots and lots of tests). Weird. Well, hopefully this helps someone who can't get their WiFi to connect: turn on Verbose logging, and then optionally back to where you had it. Maybe this was a coincidence with my specific setup? I'm at a loss to explain... :) |
It sounds like it is/was failing to complete the connection process and store the SSID data in NVS for later use. Perhaps the logging caused a timing difference which would be odd but not entirely unheard of. |
For kicks, I created a program to just do |
Something must have been corrupted in the NVS in that case, that is the only thing I can think of. |
I believe is related to #2025. |
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
I just ran into this issue on a Adafruit Huzzah32. Out of three boards one would timeout with the 4WAY_HANDSHAKE_TIMEOUT error. Downgrading from version 1.0.4 to 1.0.2 in the Arduino IDE solved the problem. |
[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future. |
I want to add that I am having this problem also on my Adafruit Huzzah32's. I just flashed 4 of them and all present this issue! It is super annoying because every time you flash them there is a chance that it will work, then once they are working then next flash may cause it to fail again. [D][WiFiGeneric.cpp:337] _eventCallback(): Event: 0 - WIFI_READY Here is the weird part for me though, it will only fail when connecting to my home wifi which is a Ubiquiti Unifi system. If I turn my phone on as a hotspot it will always connect. However when I connect to my home network it fails, unless I flash it a ton of times and once in a random flash it will start connecting again. Once it connects, powering it off / on doesn't matter it will always connect, however then next time I flash it, it will roll the dice and not connect. |
@ssilverman Thank you for the clue to go back to 1.0.2 that solved it and lets me flash my boards!!! If anyone needs me to test this I can pretty much reproduce it 100% of the time, but I'm still pretty new at this arduino thing, ie I looked for "ESP32 DevKit-C board type" mentioned earlier and I couldn't even find it :( |
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions. |
I'm after running into this problem on V1.0.4 using a Feather Huzzah32. Using "HelloServer" as the example in all scenarios, only thing I change is my SSID and password On V1.0.4, swapped to a different board and the exact same code worked fine. Created a portable version of the Arduino IDE and installed V1.0.2, connects no problem on the Feather Huzzah Then tried V1.0.4 on Huzzah again, didn't connect. Any ideas what could be wrong? |
I am just staying on V1.0.2. Maybe @atanisoft could provide further guidance on what we should be doing to troubleshoot this. |
@witnessmenow @Lopton about the only advice I can give is use a different board. A lot of people have a challenging time with the Feather line of boards, often with WiFi which appears to be signal strength or interference related |
I've had a similar issue - code was working fine for quite a while, hadn't made any changes affecting wifi connection, uploaded, failed with reason 15, found this thread, downgraded to v1.0.2, re-uploaded and was able to connect no problem. I'm not using the feather board. Arduino 1.8.12 |
I think we'll need to murder this bot. |
I have the exact same problem here, I Got an ESP32-WROOM-32E Chip and no mather what i do, on some AP, i alway got the 4WAY_HANDSHAKE_TIMEOUT. I have tried getting back to 1.0.2, install the developpement version of 1.0.4 and it is always doing the same on this those particular router/AP, on my shop Linksys router it is working fine.? |
me to |
I had also I have downgraded ESP2 to V.1.0.0 and it works!!! JEAN LUC 21 nov 2020 |
I'm trying to run a simple program that connects to a Wi-Fi access point. Quite simply, v1.0.2 can connect to a 2.4GHz access point but v1.0.3 cannot. I'm using the following code snippet, but the
WiFiClient
example works just as well for testing, after changing the SSID and password.The program never connects with v1.0.3 but does with v1.0.2.
The text was updated successfully, but these errors were encountered: