You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello.
I have a program running on the MKR1000 with latest firmware that is sending data periodically to wolfram cloud (https://datadrop.wolframcloud.com/). The program starts sending data, it can connect correctly to the server and works without problem for about 2 weeks.
After that period, the program just can't connect to the server, the WiFi101 API doesn’t return any status code (by design), so there’s no way to know exactly what’s going on or why the connection failed.
We have two devices deployed on field, both of which are connected to the same home network (but different access points) and they both fail on the same time.
As for the network environment goes, the ISP where the arduinos are working offers no public address to the clients, instead it uses CGNAT to map a pool of public addresses to various customers. This is a common practice in our country and it’s a requirement for the devices to work under this scenario.
The fact that I mention the CGNAT is because I’ve noticed that the WiFi.getTime() method is always returning 0 on both devices.
Further investigation shown that the NTP servers embedded on the ATWINC1500 firmware were not responding to queries from the public IP address used by the ISP, probably because of a ban or a rate limiting algorithm on the server side.
Switching the Arduino to other carrier fixed the problem with the internal NTP client, however we’re unable to permanently change the ISP to the one where the NTP client gets a reply.
I’ve tested by connecting using the default root certificates and by uploading the certificate to the module using the provided tool but the behavior is the same every time.
Finally it’s worth mentioning that I have two clients (WiFiSSLClient instances) that use SSL/TLS on the same board but the only one that is failing as I described here is the one pointing to wolfram.
I’m thinking that the problem might be the the Network time, because as far as I know the time should be correct in order to perform the SSL/TLS handshake.
Has anyone experienced similar issues with the SSL connection?
As far as I know, there is no way to change the NTP server names on ATWINC1500 firmware, but is there a way to set the internal clock to see if this helps?
Hello.
I have a program running on the MKR1000 with latest firmware that is sending data periodically to wolfram cloud (https://datadrop.wolframcloud.com/). The program starts sending data, it can connect correctly to the server and works without problem for about 2 weeks.
After that period, the program just can't connect to the server, the WiFi101 API doesn’t return any status code (by design), so there’s no way to know exactly what’s going on or why the connection failed.
We have two devices deployed on field, both of which are connected to the same home network (but different access points) and they both fail on the same time.
As for the network environment goes, the ISP where the arduinos are working offers no public address to the clients, instead it uses CGNAT to map a pool of public addresses to various customers. This is a common practice in our country and it’s a requirement for the devices to work under this scenario.
The fact that I mention the CGNAT is because I’ve noticed that the WiFi.getTime() method is always returning 0 on both devices.
Further investigation shown that the NTP servers embedded on the ATWINC1500 firmware were not responding to queries from the public IP address used by the ISP, probably because of a ban or a rate limiting algorithm on the server side.
Switching the Arduino to other carrier fixed the problem with the internal NTP client, however we’re unable to permanently change the ISP to the one where the NTP client gets a reply.
I’ve tested by connecting using the default root certificates and by uploading the certificate to the module using the provided tool but the behavior is the same every time.
Finally it’s worth mentioning that I have two clients (WiFiSSLClient instances) that use SSL/TLS on the same board but the only one that is failing as I described here is the one pointing to wolfram.
I’m thinking that the problem might be the the Network time, because as far as I know the time should be correct in order to perform the SSL/TLS handshake.
Has anyone experienced similar issues with the SSL connection?
As far as I know, there is no way to change the NTP server names on ATWINC1500 firmware, but is there a way to set the internal clock to see if this helps?
Thank you for any comments and feedback.
The details of the certificate used: https://www.ssllabs.com/ssltest/analyze.html?d=datadrop.wolframcloud.com
The text was updated successfully, but these errors were encountered: