I'm troubleshooting a TLS certificate problem on AMW007 and am getting this error when running tls_client command.
What is the meaning of (state: 2, code: -0x7200) error and what aspect of the TLS handshake is failing?
I cannot find a description anywhere in the documentation.
Firmware version is SILABS-AMW007-2.1.5, Gecko OS-2.1.5, AMW007-W00001
It seems like client failed to complete the handshaking with server.
Did you already download the CA cert and set the corresponding variable? Here is more about this:
If yes, then would you please share which website you are trying to connect to? If your own server, please provide the CA cert too.
Yes, I loaded the CA cert onto the module through the web setup and have tried it both with adding the cert filename at the end of the tls_client command and by setting the network.tls.ca_cert variable. Same results either way. Have also tested other regular HTTPS web sites with their root CAs (e.g. google.com) and that works okay.
The endpoint I'm trying to connect to via TLS is mqtt.mediumone.com port 61620 and I've tried using the entire CA chain file as well as each of the individual CA certs within the chain. Attached are the chain and individual cert files. This is an MQTT broker and I'm able to successfully connect to it over TLS using mosquitto_sub/_pub and the CA cert chain.
The cert files are all unix line endings (\n).
Any updates on this?
Or a description of what the "AMW007 Error with TLS handshake: (state: 2, code: -0x7200)" error code means in enough detail to identify the underlying problem?
I am travelling for a business trip and back on March 18th. I will get back to you regarding this issue as soon as possible.
I tested AMW007 with AWS IoT and found the following:
I've tested several different mqtt broker tls endpoints and it seems that many of the "newer" ones generate -0x2700 or -0x7200 error codes and fail to connect.
Seems we are stuck with the same issue.
I was unable to connect to AWS IoT MQTT server until you mentioned using the legacy endpoint; Thank you!
Legacy endpoint = 'xxxxxxxxx.iot.ap-southeast-2.amazonaws.com'
CA = VeriSign-Class-3-Public-Primary-Certification-Authority-G5
AWS MQTT port = 8883
I have setup an AWS Lambda Rest API and CANNOT connect to that either:
URL = https://xxxxxxxxx.execute-api.ap-southeast-2.amazonaws.com/default/LambdaExample
CA = AmazonRootCA1.cer or AmazonRootCA2.cer or VeriSign-Class-3-Public-Primary-Certification-Authority-G5
Port = 443
Result = 'Error with TLS handshake: (state: 3, code: -0x7200)' and usually firmware crash (RAM overflow?)
Test Mosquitto server:
Can connect to 'test.mosquitto.org' unencrypted with 'tcpc test.mosquitto.org 1883'.
Cannot connect with tlsc and CA on port 8883
URL = test.mosquitto.org
CA = mosquitto.org.crt
Port = 8883
Result = Error with TLS handshake: (state: 4, code: -0x2700)
Please share if you are able to connect to other services.
Thanks again for your post.
Hi Greg and Matthew,
We are aware of the AWS IoT Amazon Trust Services (ATS) endpoint issue and looking for fix. Meanwhile, would you please use the legacy endpoints till that is identified and fixed.
Does this same known issue also extend too...
I was unable to connect to these services using their provided CA's (see above post by me for details).
Please let me know if I should open another post regarding this.
And as I mentioned in my original post on this thread, I am unable to connect to the mqtt.mediumone.com:61620 TLS MQTT endpoint.
Hi Greg and Matthew,
So to sum up the posts above, device is currently failing connection to these servers:
I've passed that to the R&D and will get back to you with some analysis shortly.
Matthew, I will go ahead and close this post for duplication:
Hi Greg and Matthew,
I've got sometime to look into these traces, and I do confirm that error 0x7200 you see is caused by large fragments sent by TLS server. Our module AMW007 is only capable of handling TLS fragments of 4k and less due to the memory limitation of the hardware. The new ATS endpoint (including AWS Lambda Rest API) and mqtt.mediumone.com are both sending larger fragments.
At the moment, ZentriOS 1.5 and Gecko OS 2.1.5 do not larger records, and no workaround for that at client side. Actually, the TLS Client Hello message from our device is clearly stating the max_fragment_size in the extension, but that is ignored by the server (unfortunately, the RFC does not obligate servers to honor this request. It is optional)
We are looking into some enhancement to the stack to increase the free memory, and the R&D are looking into a fix hopefully coming next release. Once the fix is introduced, I will reply to this post and let you know.
Hope that helps.
Just as a quick update, we are planning to release a new version of Gecko OS that addresses the large fragment sizes issue by end of this month. We are expecting device will be able to handle fragments of up to 6k (or more depending on the available memory, as the allocation will be dynamic). Please update your devices to latest firmware once published end of this month.
AMW007/AMW037 is a fixed function device, and does not support native apps hosted on the device itself due to its limited resources. Nevertheless, device can be easily paired with an external host that drives it. The host can run whatever protocol it desires, and communicate over UART with AMW007 which runs a complete TCP stack. Here is an example to use external MCU (Giant Gecko) that is running MQTT, and uses AMW007 for TCP commands (i.e., NCP):
You can replace the Giant Gecko with any MCU of your choice, and port whatever stack you want as well.
Hope that helps.