Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection failed to HTTPS URL #264

Closed
geekfactory opened this issue Jan 8, 2019 · 2 comments
Closed

Connection failed to HTTPS URL #264

geekfactory opened this issue Jan 8, 2019 · 2 comments
Assignees
Labels
status: waiting for information More information must be provided before work can proceed

Comments

@geekfactory
Copy link

geekfactory commented Jan 8, 2019

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

@Rocketct
Copy link
Contributor

Hi @geekfactory could you share a minimal sketch to reproduce the error? have all updated?(ATWINC1500 firmware 19.6.1 and wifi lib 0.15.3)

@sandeepmistry sandeepmistry added the status: waiting for information More information must be provided before work can proceed label Jan 30, 2019
@sandeepmistry
Copy link
Contributor

Closing this for now due to lack of feedback. Please re-open with requested information if you are still interested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting for information More information must be provided before work can proceed
Projects
None yet
Development

No branches or pull requests

3 participants