cesanta/mongoose

Can't reconnect websocket connection after getting a "DNS timeout" error

luisyague opened this issue · 1 comments

luisyague commented
  • My goal is: to know the correct way to restablish the websocket connection after getting a DNS timeout
  • My actions were: I just left my device running with mg_log_set(MG_LL_VERBOSE) set, this error comes up every day more or less. I've seen this behaviour since earlier versions of mongoose (I've been using since version 7.6)
  • My expectation was: I expected to be able to restablish the websocket connection without having to reboot the device
  • The result I saw: I attach two logs: in "log_mongoose_ok.txt" a correct connection is showed, in the "fail" file it shows the behaviour after the DNS timeout error., after this error the device is not able to reconnect the socket.
    log_mongoose_ok.txt
    log_mongoose_fail.txt
  • My question is: what is the correct way to reconnect the socket after getting this error? Currently I have a supervisionTask which reboots the device after getting two of these errores but I would like to avoid it.

Environment

  • mongoose version: 7.14
  • Compiler/IDE and SDK: ESP-IDF 5.2.2
  • Target hardware/board: Custom Board
  • Connectivity chip/module: ESP32 WROOM 32 E
  • Target RTOS/OS (if applicable): FreeRTOS

Thanks a lot in advance!!!

scaprile commented

It is impossible to know what you are doing if you don't show what you are doing
It is impossible to know what happens if you don't show what happens.
There is no "socket reconnect" problem, your DNS resolution is failing, how do you expect to connect somewhere when its name can not be resolved ?
Why is the DNS resolution failing ? It is your network, you should know better than I can guess. Is your WiFi connection going down and up ? You are not expecting sockets to remain usable after a connection change, are you ? If your connection is not stable, you must close all open sockets and open them again. That includes the DNS resolver, so the best way is to free the manager resources and start again.
Knowing what is going on, with a proper network capture, maybe the answer would be different