Will not reconnect to WiFi if signal is lost
evazzoler opened this issue · comments
I tried all the versions available, bin or source but still happens that issue:
if the AP for any reason fails or reboots, esp-rfid won't reconnect until I push the reset button.
I read a issue talking about a missing mqtt reconnection, but I notice a missing WiFi reconnection.
Another useful feature (maybe optional with a checkbox) would be "reconnect to another given (for avoiding MITM attacks) BSSID, same SSID if choosen AP fails"... That would prevent both AP failures and deauth attack.
Thank you in advance for fix and optional improvement.
Probably the same or at least related: after a power failure, my ESP-RFID powered up faster than my wifi router, so the ESP-RFID failed to connect to wifi and didn't retry, remaining offline until I power-cycled it.
Issue #251 is similar but not the same, plus mine contains a suggestion/feature request.
We can summarize there are 2 different problems:
-
referring to issue #251, when esp-rfid can't find the AP at boot, it goes to AP mode. It is a sensitive issue because the "recovery mode" should be preserved, so the AP mode should not be eliminated but better implemented including a frequent (i.e. 1/5 minutes) reconnect retry.
-
referring to this issue #437, when esp-rfid is booted and connected and it loses the AP without restarting, it don't try to connect another AP. It would be not correct to let it reconnect to any AP with the same SSID (secutity reasons) but it would be a good idea to let it connect to an optional backup BSSID defined in the configuration and periodically check if the main AP is back, in order to reconnect it.
I have implemented some "secondary" features that are currently working only via MQTT, like one-time-pins, xx-time-tags or tags that are authorized to open the door only when alarm system is disarmed. In the standalone mode (AP lost) esp-rfid will accept only local tags.
Issues at point 1. and 2. are making almost useless my implementation.
Hi, I finally realized that this is a security lack. Unauthorized people will have access!
- AP normally boots in longer times than esp-rfid
- If I have access to the main current meter (normally installed ouside a building) I turn off them on the mains.
- esp-rfid will go to recovery mode because it can't find the AP at boot
- I connect to the esp open network from outside
- I test the relay and open door
Recovery mode must be (optionally) disabled and one time enabled via UART once needed!
Please, consider this security improvement!
You should change the admin password. It is not a security lack if you put a custom password.
This is a big problem in my implementation. I am not using the relay function in esp-rfid at all. Everything is run via MQTT, and in any case where esp-rfid falls back to recovery, no door locks will function. That means whenever there is a powerout or I reboot my wifi router or AP, I will need to manually go around and reboot every esp-rfid.
Pretty please, can we have an option to disable recovery mode, and let the esp-rfid try the configured SSID until success, like all other wifi devices?
This is a big problem in my implementation. I am not using the relay function in esp-rfid at all. Everything is run via MQTT, and in any case where esp-rfid falls back to recovery, no door locks will function. That means whenever there is a powerout or I reboot my wifi router or AP, I will need to manually go around and reboot every esp-rfid.
Pretty please, can we have an option to disable recovery mode, and let the esp-rfid try the configured SSID until success, like all other wifi devices?
Strongly agree. Why not adding another configurable pin to optionally enable recovery mode (on next boot?) ?
Pull requests are always welcomed.
Hi, is there a solution for reconnecting Wifi after lost signal?
hey @bgnaedig it works for me on the dev branch. Can you try the dev branch with the debug target? It should output a lot of logging on the serial port. If you are able to share that I can understand better what's going on for you.
I'm closing this for now as no additional feedback has been provided and the latest PR: #495 on the dev branch adds a bit more functionality for this.
Please reopen if needed though.