After 1.0.6 update WiFi won't connect to other network // connection time increased

[handmade0octopus]

Hello.

Using ESP32 with arduino.

Below snippet was working ok on all previous versions. I updated today to 1.0.6 and now it won't connect to my home network, always creates Access Point instead.

WiFi.begin(wifiSSID.c_str(), wifiPSWD.c_str());
	while(WiFi.status() != WL_CONNECTED) {
		if(millis() - startTime > 2000) break;	
		delay(100);
		tft.drawCentreString(CONNECTING_WIFI, OFFSET_WIDTH, OFFSET_HEIGHT+WIFI_OFFSET_HEIGHT, 1);
	}
	if(WiFi.status() != WL_CONNECTED) {
		WiFi.disconnect(true);
		WiFi.mode(WIFI_AP);
		delay(100);
//		WiFi.softAPConfig(local_ip, gateway, subnet);
		WiFi.softAP(wifiSSID.c_str(), wifiPSWD.c_str());
		delay(500);
		IPAddress IP = WiFi.softAPIP();
		tft.setCursor(10, 230);
		tft.println(IP);
		wifiOn = false;
	} else {
		wifiOn = true;
		tft.setCursor(10, 230);
		tft.println(WiFi.localIP());
	}

Reverted back to 1.0.5 and 1.0.6, power cycled device many times and nothing helps. Once I use 1.0.5 everything works as it should.

[me-no-dev]

can you enable debug to Verbose and post the log? WiFi is working fine on my end

[handmade0octopus]

Sure:

1.0.5 log:

[E][vfs_api.cpp:64] open(): /sd/update.bin does not exist
        
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 0 - WIFI_READY
              
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 2 - STA_START
               
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 4 - STA_CONNECTED
           
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 7 - STA_GOT_IP
              
[D][WiFiGeneric.cpp:419] _eventCallback(): STA IP: 192.168.1.79, MASK: 255.255.2
55.0, GW: 192.168.1.254
                                                       
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 3 - STA_STOP
                
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 3 - STA_STOP

And here is 1.0.6 and only AP working ok:

[E][vfs_api.cpp:64] open(): /sd/update.bin does not ex
ist
                                                                           
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 0 - WIFI_READY
              
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 2 - STA_START
               
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 14 - AP_START
               
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 0 - WIFI_READY
              
[D][WiFiGeneric.cpp:374] _eventCallback(): Event: 14 - AP_START

[me-no-dev]

I think you should wait a bit longer than 2 seconds :) logs does not show that connect failes

[handmade0octopus]

I think you should wait a bit longer than 2 seconds :) logs does not show that connect failes

Fair enough but why I NEVER had any problems with 2s waiting time?

Never ever had any issue and I do it this FW for over a year. Now with 1.0.6 it NEVER connects within this 2s period.

What you changed in the code it lost its performance? I think this is worth finding out to be honest. I am happy to run some tests if you want.

Changing to 3000 "solved" issue but I call it a bodge as performance loss of 1s is big thing don't you think?

I ran some benchmarks and on 1.0.6 I got between 2200-2420ms

On 1.0.5 on other hand I have 220ms - 1100ms (while most being around 260-330ms!)

What is the reason behind this huge performance loss?

I will stay on 1.0.5 till this is resolved.

[ThomasWaldmann]

ecocurious2/MultiGeiger#408 we also encounter wifi issues with 1.0.6.

[zasnicoff]

1.0.6 also broke my code, not much to report at this point, but I'll keep you posted.
PlatformIO, upgraded espressif32 to 3.2.0 / Board: m5stack-core-esp32 / Framework: arduino

• Unable to connect to WiFi Access Point, board in STA or AP-STA modes;
• Unable to access "captive portal" through cell or PC, board in AP mode, using WebServer.h and DNSServer.h;
• User buttons in board seem to be triggering on their own after connection failure. Found a possible related issue: M5.BtnA.wasPressed() conflicts with WiFi? m5stack/M5Stack#52

All the above working fine before upgrade.
As a side note, WiFi Scan is taking considerably longer, I guess it's related to the new DELAY code / looking for stronger APs.

Looks like WiFi is causing a pulse in GPIO39 and this is an issue for certain boards that rely on this pin.

[eyecee]

Same issue here using WiFiMulti; upgrading to 1.0.6 has broke my WiFi connection code as well with all the same issues listed above. It feels like the overall connection process in 1.0.6 is taking significantly longer than 1.0.5 which has caused a lot of people's timeouts to trigger. Wifi connections under 1.0.5 was working 99.5% of the time with the 0.5% usually attributable to external factors.

I'll revert to 1.0.5 for now but keen to see this issue solved as there are other upgrades to the ESP32 library that has improved, e.g. SD_MMC library.

[zencow]

I just wanted to chime in with my own experiences. I've had code running on a esp32 (Adafruit's Huzzah32) for more than 6 months before breaking my device last night with all the latest versions recently updated in the Arduino interface. After finding this thread, I did some quick tests rolling back from 1.0.6 to 1.0.5 (from February) and then to 1.0.4 (from October).

• 1.0.6 - connecting with WiFiMulti was taking about 15 seconds. connecting to Adafruit IO (mqtt service) never reported success.
• 1.0.5 - connecting with WiFiMulti dropped to about 6 seconds. connection to Adafruit IO never reported success.
• 1.0.4 - connecting with WiFiMulti dropped to about 2.5 seconds (what I expected). connection to Adafruit IO works again.

I duplicated these results using the stock WiFi example code, using "Simple Time" as a baseline against "WiFiMulti" example code (only adding serial print commands with millis() for showing time before and after connect), and the WiFiMulti connection was slower with 1.0.5 and 1.0.6 quite consistently, with similar times as listed above. Note, I was using just 2 sets of credentials for WiFiMulti in all of these tests, with only 1 of the 2 ssids within range.

[stale]

[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.

[ThomasWaldmann]

If nobody fixed this, there is no reason for a stupid stale bot closing this.

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.