Description
During a normal client connection, there are periods within execution that the client fails to connect with the server immediately without any noticeable delay. (This means that in my serial logs, the program would print a connection attempt, and immediately print that it failed.)
My code essentially can be boiled down to this:
// Use WiFiClient class to create TCP connections
WiFiClient client;
// WiFi MAC address should be populated at this point!
if (client.connect(server, 80)) {
// do stuff here
} else {
Serial.println("ERROR: Connection failed!");
Serial.print("WiFi.status() = ");
Serial.println(WiFi.status());
}"Do stuff here" executes successfully for the first few data transmissions, and then begins to fail afterwards for a significant period of time, usually for 2-6 minutes of failed connections before sparsely succeeding again.
Upon enabling debugging on Serial, as well as Core+WiFi debugging, I see this:
[hostByName] request IP for: example.com
[hostByName] Host: example.com IP: xxx.xx.xxx.xxx
:ref 1
...
[hostByName] request IP for: example.com
bcn_timout,ap_probe_send_start
[hostByName] Host: example.com lookup error: -5!
ERROR: Connection failed!
WiFi.status() = 3
Collecting data...
- Current mid thresh: 500
- Current high thresh: 600
Transmit NTP Request
:urn 48
Receive NTP Response
:urd 48, 48, 0
...
[hostByName] request IP for: example.com
[hostByName] Host: example.com lookup error: -5!
ERROR: Connection failed!
WiFi.status() = 3
At the very beginning, hostByName succeeds. After a few lookups, however, it begins failing as shown above.
I've traced this message to here, where there is some info about the message printed. Searching the error codes leads to this header, which defines each error semantically. -5 seems to be the IN_PROGRESS error, which seems to get handled but does not seem to pause for execution to succeed.
As an additional check, I tried using the latest version on Git (with the newest SDK 2.1.0 branch), and this problem seems to occur there too.
Is this an error on my part (as in should I be specifying a timeout of some sort?), or is there some sort of strange handling going on in the library?