The test works on my PC indicating a valid IoT thing and certificate.
When I connect using the provided micropython code using the example from the same page I receive the error, OSError: [Errno 7115] EINPROGRESS , on the ussl wrapped socket.connect call. I have tried the Starfield and the Verisign CA. I have also tried the MQTT test code found on this post, https://forums.digi.com/69824/help-connecting-xbee-cellular-to-aws-console?show=69824#q69824 .
I intend to ultimately use self signed certificates for my EC2 host MQTT server, so if there is a better method via a self signing procedure that would be acceptable as well.
I could not get the modem to connect to my server using my self signed certificates even though my desktop could, so I would like to understand what the modems certificate limits are so I can learn how to create valid ones.
If you move the s.setblocking(False) line to after the w.connect call, the example should work fine. Or, you could change it to:
import uerrno
while True: # TODO time out eventually?
try:
w.connect((aws_endpoint, 8443))
break
except OSError as e:
if e.args[0] != uerrno.EINPROGRESS:
raise
(I apologize, I cannot format this code with correct indentation. Hopefully you can tell what it’s meant to be.)
We will work on updating the sample code to reflect the fact that if you use s.setblocking(False) before calling connect, you must call connect in a loop and continue calling connect until it stops raising OSError EINPROGRESS.
The sample code you are using was not updated after the 1016 firmware was released, which is when support for nonblocking socket connects was added. (In earlier firmware, the connect call would block there.)
Thanks for the input, I tried both the relocation of the non-blocking flag and the while loop approach.
When I move the non-blocking flag and leave all else the same, I get an EIO error after a few seconds.
When I try the while loop option, the EINPROGRESS becomes an ENOTCONN after the INPROGRESS error clears. However the device never successfully connects.
To verify modem/uPython REPL connectivity I tried a non-ssl mqtt pub via upython to test.mosquitto.org. My test MQTT pub was successful so I’m confident in saying my problem is down to something in the SSL wrapping process. I verified that my certs work on my desktop prior to moving them to the modem. I tried the verisign and starfield ca’s, neither showed any difference in behavior.
Updated XCTU and tried on both windows and linux. I still get the ERROR with ATMV. I double checked and I am using the ca you attached. Not sure if it matters but I tried with both the .ca and .crt extension didn’t seem to make a differnce. Should I roll back to older firmware? Maybe the latest that supports the flash file system?
No, I don’t think rolling back to older firmware will help. The ATMV command should not give an error, unless you’re running the command incorrectly (such as sending any parameters with the command).
Can you confirm whether the AI parameter reads as 0? If AI is stuck at a value such as 0xFF or 0x22, the XBee is not connected to the Internet and that could explain the errors you have been getting. Or if it reads 0x24, use XCTU to reinstall firmware version 1016 – XCTU will attempt to update the cellular modem.
SUCCESS!
I reflashed my modem to latest(accidentally because I selected a lower version and was trying to downgrade)
After the reflash it actually hung on the last step and said it couldn’t read block 205. I was worried I bricked it but proceeded to restart and test anyway.
ATMV succeeded this time with response,
23.00.006 (M0A.00060)
I tried the test TLS HTTP code again and it worked this time!
In conclusion, I definitely had some sort of glitch going on in the modem. Firmware reflash appears to be the thing that fixed it.
I am using the starfield ca you referenced. Now I get to see if it worked with my self signed cert and I’m in business. Thanks for the support on this.
That’s great! Yes, the problems you were hitting (mainly that ATMV gave you an error and some other data) seems to point to the Telit modem being glitched or having somehow gotten reconfigured in a mode that was unusable. Reflashing it reverts it to default settings, which the XBee can then use.