WiFi Auto Reconnect Still Not Working - Is there a best practice to guarantee connection? #653
Comments
|
can you please enable debug in the board menu and see why it does not want to reconnect when you tell it to do so? |
|
I can try that tonight. The Arduino code is pretty basic, watching the WiFi event and then has this: But shouldn't there be something that can be called to make this happen on it's own? |
|
Just for a quick fix: |
|
Unfortunately I'm adapting someone else library and I'm not very familiar with C++ but I'll see what I can do about adding a timer (I know VB.net...I can at least figure out the logical parts and hopefully adapt). But I think you are right about it not reconnecting or better yet only trying on a disconnect which then if it fails just once it give up. Enabling debug might show me that so I'll start there. But back to the original question and the previously closed issue: Is this functionality not built-in? And if not why was the previous issue closed as "kind of" working? Also if not will it be? |
|
I switched the debug level to debug and opened serial monitor and got this over and over: I checked the last time it sent data to another controller and that was over 24 hours ago so I'm assuming its stuck in this mode. So I powered it down and back up, it connected to WiFi just fine and transmitted data how it should for about 2 hours this time. Then without any other message it disconnected and started with the exact same message over and over. I let it go for a hour, rebooted the controller, and its connected again but I'm sure its just a matter of time before it starts over. So the first question is how do I fix it. Second this still leads me to my previous questions about auto reconnect |
|
Guys please enable debug so you can see more verbose WiFi state output: |
|
I use the following code to check if my device is still connected to the STA (call this from loop()). You get the idea? wifi_is_connected is a global that gets set and reset in the wifi event callback. |
|
Yeah, I don't see a Loop() in the library I'm using for WiFi (again, third party) but I understand what you are doing and can run with it. Going to turn on the verbose logging and see if I get any more info first before changing anything. Also the WiFi Events that are being checked and acted on are SYSTEM_EVENT_STA_GOT_IP, SYSTEM_EVENT_STA_DISCONNECTED, SYSTEM_EVENT_STA_START, and SYSTEM_EVENT_STA_CONNECTED. There are more however at https://github.com/espressif/esp-idf/blob/master/components/esp32/include/esp_event.h so I added a default: to the switch that should print out the event to see if the library is getting something but just not acting on it. I saw in the library I'm using a //WiFi.setAutoReconnect(true); so I'm assuming the original author tried to use auto reconnect but it wasn't working so commented it out? |
|
@me-no-dev - Verbose gave a much better explanation. Well...maybe to you: Everything was fine then got this over and over, maybe 150 times:
Followed by this: The the last part (reconnect, event 5, reason 2) just repeats every 4 - 5 seconds. |
|
Based on that first error that repeats over and over I found this: #180. In it you said "Try flushing the client or reading all available data. ". How would I go about doing that? I'm looking at the library I'm using and this is what they have to catch the WiFi Event: Based on the errors in the previous post I'm getting the "5" which is translating to the WiFi connection lost and then the code is trying to execute "WiFi.reconnect();" but its obviously not working. Should I have something else there? Maybe a counter kinda like @everslick example but simpler (just a i = i + 1) and if it end up on the same place after 20 tries it reboots? Or should this not happen/be prevented in the first place? |
|
Try calling WiFi.begin() instead of reconnect and report back :) |
|
@me-no-dev - I changed it to WiFi.begin() instead of WiFi.reconnect() but it didn't help. Worked for about a hour then got the lwip_connect_r:113 line, each one about a minute or so apart followed by the disconnect every 5 or so seconds: And then the 4 lines just repeat indefinitely until the control is rebooted. What else can I try? The fact @everslick is rebooting the controller when its in the same disconnected state is worrisome....I would think rebooting is the last option and something can be done to keep it online. As a side note two ESP8266's connected to the same router (Netgear R8000) have no issues and have been stable for over a month without disconnects. |
|
hmmm.... this seems like an issue either in the lower stack or in your router. |
|
Its a Netgear Nighthawk R8000. Currently on the latest firmware V1.0.3.54_1.1.37 although it did it on the last version also. I have 20 - 25 devices connected at any given time without issues including the previously mentioned two ESP8266's. I will attempt to replace the Wi-Fi begin/reconnect line with the STA off and on and see what happens. Edit: Knowing not much about this and using someone elses library....how do I "turn off the STA and then turn it back on"? Second Edit: It couldn't be related to espressif/esp-idf#499 (comment) could it? One of the only things I've seen with the same NOT_ASSOCED and AUTH_EXPIRE. I wouldn't think so only because I compiled myself without the BLE stuff but never know. |
|
I have also alerted the wifi team :) we will see if anything comes out of this |
|
Thanks. Should I be trying to do the STA off and on? If so can you guide me how or point me in the right direction? I also saw this: espressif/esp-idf#738 (comment) which indicated that I can't call the WiFi.connect or WiFi.Begin from the event handler? Could that also be my issue? @rojer ? |
|
So I bought a second ESP32, same one, to try and make sure it isn't a hardware issue. I recompiled the firmware yesterday night off a fresh pull from github (https://nodemcu.readthedocs.io/en/dev-esp32/en/build/) and flashed both the new chip and the old one. I also flashed both with the exact same sketch. The original is in my garage, a little ways from my router, and the other test one is in my living room where the WiFi is a lot stronger. Both have serial monitor running on a connected PC with verbose set. I'll report back anything I find. With the above said is there anything else I can try? How do I do the STA off and on? Can that be done in the STA_Disconnect part where the WiFi.reconnect is? |
lonerzzz
changed the title
|
Well that didn't last long....I'm having the same issue with the new one. First the original one started with the same "[E][WiFiClient.cpp:97] connect(): lwip_connect_r: 113" error and not sending data after barely 30 minutes online. Usually got that error two at a time with about 5 or 6 seconds between then then 45 - 50 seconds between the next set but again kinda random. Did that for around 10 minutes then went into the same disconnect pattern: And repeated the last 4 lines over and over. At one point it did do something different...the error message changed slightly: Notice the error switched to ending in 118 as opposed to 113. But from that point on it just repeated the 118 error randomly along with the STA_DISCONNECTED and AUTH_EXPIRED over and over. Then the new ESP32 started doing the exact same thing. mostly 113 error then the same pattern of NOT_ASSOCED, ASSOC_FAIL, and AUTH_EXPIRE followed by just the disconnect and AUTH_EXPIRE over and over. They failed at different times, 25 minutes apart, while they were started at the exact same time. WiFi signal doesn't seem to be a factor nor does any certain timing. Edit: Just to be clear on a reboot it connects instantly on the first try every time: |
|
Still waiting on response from the WiFi team. Will make some more noise as this is annoying to me as well. Issue is somewhere way below Arduino and in the closed source wifi lib. |
|
Thanks. I'm going to attempt to add a counter to the STA_DISCONNECTED event switch statement that I keep getting and after 5 try to re-init the wifi and after 10 reboot the controller and on a connect reset the counter to 0, see if that at least keeps the controller up. If there is anything else I can provide you to help get this fixed or code to try please let me know. If it matters the ESP32 I'm using is being used for two voltage inputs, one binary input, and a DTH22 (temp + humidity) then that data is being sent to a controller through HTTP. |
|
Hi @vseven, I just can't reproduce this issue myself, could you let me know the firmware version of WiFi? You can get if from the startup log, it looks like "I (588) wifi: wifi firmware version: 2cd69aa", then I can provide a debug version wifi lib to you to debug this issue. |
|
@vseven could you let me know the WiFi reconnect logic? I means when to call esp_wifi_connect()? It will be helpful if you can paste the implementation logic. |
|
Ok, I commented out that line and recompiled. I'll report back. As a side note I tried to add a counter to reconnect by recalling my init() but it didn't do anything....it was like the init() was never called. I might be doing it wrong though. But when the counter got to 10 the ESP.restart defiantly was called and rebooted correctly which afterward it reconnected: @liuzfesp - here is the extra info with that line commented out: And the files I'm using (before I added the disconnect counter): |
|
@liuzfesp - So it did the same thing with the debug enabled, hopefully something in here will tell you something. It ran fine for a hour or so then started throwing the 113 error randomly. After about 15 minutes of random 113 errors in between the actual data sending routines it did this: So for each STA_DISCONNECT it tried calling WiFi.reconnect with no apparent success then it tried running init() after more then 5 disconnects which also didn't help then once it hit 10 disconnects it rebooted which did reboot and reconnect. |
|
I kept serial monitor running on my ESP32 all weekend and it rebooted about 10 times between 6pm Friday night and 9pm Sunday night. Each time it was exactly like the above logs. @me-no-dev - can you guide me in a way to just turn off and back on the STA to see if that also works for reconnecting and I can try that after 5 failed attempts? The reboot after 10 works but I plan on using this to control RGB lighting and I really don't want to have lights turning off and on. @liuzfesp - Is there anything else I can provide you with for debugging? Or anything that stands out I can try? |
|
Any updates? Still have constant disconnects with both devices. |
|
@liuzfesp any news here? |
|
@Miq1 does this issue exist if only use IDF example? |
|
I must confess that I am using the Arduino in Platformio environment only - I never dealt with the IDF. I will look into it today to see if I can set up a basic version of my application there. |
|
Just for the records: I found that the workaround with disconnect() and subsequent begin() works for me if I do a mode(WIFI_OFF) and mode(WIFI_STA) in between. I am currently trying the reconnect 5 times in a row and would do an esp.restart() if all attempts failed, but so far no restart was necessary. |
|
I observed a few restarts in the meantime, so the workaround seems not to be as effective. |
|
Is there any update about this bug? |
|
FWIW I see this often on ESP8266 units too - exact same symptoms. I've found I can change the connect quite drastically simply by orienting the unit differently - so it seems to be related to how the units (both ESP8266 and ESP32) respond to bad signal. Given I am using NonOS and an ESP8266, the common denominator seems to be the low level networking below lwIP |
|
(Using 1.0.4 version of Arduino-esp32) I had the same problem here (using ESP32). Found that rebooting the router solves the problem... once. That is, after the reboot, the ESP32 is able to connect to the AP, get an IP address and stay connected, but if something causes the connection to fail (like rebooting the ESP32), the ESP32 then is never able to connect to the AP again. The router is a TP-Link TL-MR2030 that I keep around for wired ethernet tests and has firmware that is hopelessly outdated by years and no newer official firmware exists. However, if I try to use other APs, like some quite new Ubiquiti units at the office, the problem simply does not happen at all. I even raised some suspicion on the IT staff by forcing the board to purposely reboot and reconnect repeatedly as fast as possible for hours on end... and no trouble at all. So, in the end, while it is possible that something is wrong or incomplete in the ESP32's libraries, I am ready to put all the blame on the old router's firmware. Time to get a new router for tests, not from TP-LINK, however. |
|
I usually suspect dns for things like this. Or sometimes the router still thinks you are connected and never allows you to reconnect |
|
No, the router is not to blame. At least in my case. Sure, it's not the newest (wnr2200) but with an up-to-date DD-WRT installed and several android, linux and windows devices working without issues. To finally solve this issue for myself, I started over with a completely new implementation, based on WiFiClientEvents.ino - so it's event-based. I also read the newest commit messages of arduino-esp32 which revealed very recent but relevant commits. I had to do some debugging in WiFiGeneric.cpp and found that mode doesn't always do what's expected (#1306). Final result: with a little patch on WiFiGeneric.cpp (see end of file), I was able to connect and disconnect several times to/from my AP - hurray :) Let me know if you see something to improve. |
|
Has anyone wiresharked this? Had a similar issue with an arduino wifi rev 2 (different hardware, but issues negotiating between ap's and the device was eerily similar.) |
|
@mrarmyant What do you expect to see using wireshark? I think we are talking about issues on OSI layers 1 and 2. Differently said: no SSID, no frequency, no packets My code (above your post) runs stable since I posted it. But I don't think the problem is portable to something different than ESP* chips because it addresses issues of the ESP SDK, not Arduino |
|
I blame issues like this on power supply |
|
i wouldn't blame the PS, it's very unlikely unless you have a really weak supply this will not happen. Wireshark is really useless here. To understand you have to dig deep into the RTOS libraries where the real work is done, not the Arduino libs as they are a wrapper. If you are using WiFi.reconnect() instead of WiFi.begin() you need to know a few things. WiFi.begin() starts by setting all needed registers on the wifi chip and RTOS states before connecting, reconnect() does not. WiFi.reconnect() often makes only half of the connection, establishing a chip level MAC connection with UDP but never making the TCP/IP connection as these are separate protocols. This is due to needed states not being preset by reconnect() it simply assumes they are there. Remember; reconnecting is needed because the states have already changed. I ALWAYS reconnect with WiFi.begin() and have never failed. ====== A simple delay on boot before connecting has fixed this for me every time. A good start timer will help here. I have been using the ESP32 for over 6 years and this has always worked. |
|
UPDATE; i see a lot of WiFiEvent used and for debugging its good but to simply detect wifi down and reconnect the IF/ELSE below works reliably every time. this works because it takes about 18 seconds from down to reporting WL_CONNECTED change, this gives the DHCP server time to release the IP for a reliable re connect later. It has been working for over 6 years and counting. take a look at the skeleton code i posted on #1100 though it was for setup with SmartConfig it just works. |
I wasn't referring really to arduino, but the wifi soc that is onboard that particular unit. It had issues with reconnect based on being hinky with dhcp. Someone reported that restarting their router fixed it, which is the problem we had (well restarting a windows dhcp server). There was an issue with the way it was acknowledging wether or not it had been disconnected. Just thought it might help with those issues up there, because neither unit would ever show as connected on the reconnects, and wireshark showed us why. Static IP's had no problem. It ended up being the wifi soc firmware that had to be fixed to handle the delay mentioned for DHCP issues. All of which were discovered via wireshark. |
|
Hey, don't mean to bring up an old issue, but currently on my esp32 board Lilygo TTGO T5, if I kill power to it whilst it is connected to the network then power it back up, it will not auto reconnect unless I power it off and on again, it will connect on the second attempt. If I add a delay of 35 seconds before the wifi connection portion it always reconnects. If I do (wifi.disconnect();) to kill the wifi cleanly once I an done using the wifi then kill the power it reconnects fine each time. The delay is a work around but not ideal, would be good to get to the root cause of this issues, is it a access point thing it an esp32 thing? See here for more detailed info Hieromon/AutoConnect#292 |
|
@Anton2k When connecting the ESP32 will request the same IP if possible. your delay is a well founded solution this WiFi skeleton code has served me well for over years thru several processors. |
|
@mickeypop Thanks again for your suggestion, I have had a deeper look into the lib I am using and the auto reconnect time out is set at 30 seconds, mine needs 35, so by changing the time out figure I should be good! thanks again for your help. One little thing that is still niggling me, if power of the ESP32 and power it back on and then off again and back on (both in quick succession, within 2 or 3 seconds of each other) it will always reconnect on the second attempt regardless of how long I have waiting, again I will really need to test this again to make sure I remember it correctly, but I am fairly certain. Do you think it's possible that if the ESP32 makes a connection attempt soon after another that the router might be auto releasing the DHCP ip? Thanks |
thank you thank you thank you very much, I've been looking for this solution for a week ... and now you and this page have helped me ;) 35 second :) |
Very welcome and glad it helped someone! :) |
|
The every second connect is typically a deauth protection failure, you need to get debugging wifi failure event codes. |
|
I have the same problem with the inability to reconnect to the access point. Symptoms: Followed by endless reconnection. Solutions that didn't help: solution that works:
I hope it will be useful to someone |
and others
Board: ModeMCU ESP32 Dev Module
Core Installation/update date: 15/Sep/2017
IDE name: Arduino IDE
It seems there is no auto reconnect logic allowing the ESP32 to reconnect when the connection drops or if there is its not working properly. I have had completely random results with my ESP32 board, sometimes its up for as little as 30 minutes and at most 18 - 20 hours. WiFi is dropping and doesn't want to reconnect.
The library I am using for WiFi is watching the WiFi event and on a disconnect its trying to reconnect which helps but sometimes it fails the reconnect and then that's it...I have to reboot. There is no sleep/low power mode at all involved and the device is constantly powered by 3.3v in. There was a case opened regarding this, #353, but its closed without any real answer (says auto connect is kind of implemented...not sure what that means).
I guess the question comes down to is auto reconnect implemented in the code itself, reliably, and if not what is the best Arduino code way of making sure it is connected?
-Allan
The text was updated successfully, but these errors were encountered: