After reading
https://discourse.electricimp.com/discussion/comment/21136/
I’m guessing my problem is similar since when I change from https to http, all of my messages make it through fine to SNS instead of just a few.
Obviously, since I don’t have access to SNS servers to figure out what is going on, does anyone have any ideas? I would prefer not to POST in the clear.
35 is CURLE_SSL_CONNECT_ERROR, a different error from that other thread. I’ve raised a bug to investigate.
Can you post code that replicates the issue (without any keys, etc)? We’d like to replicate and tcpdump the session to see what exactly is upsetting libcurl about the SSL connection.
I’ve attached the agent and device code. I’m using the April board with the EnvTail. Change line 17 in agent from https to http to see it “work.”
The response isn’t “successful” because I’m still working on getting the v4 signature code working. However, I am getting a valid bad response which is ok for now.
Have you guys had a chance to look at this yet?
No but we’re looking at some Amazon stuff right now so stay tuned.
Because the setup here is a bit hard, could you contact us at info@electricimp.com so we can discuss monitoring your requests (pass/fail) for easier debug?
@darinpope I’d love some feedback on my AWS request library if you have a chance!
https://discourse.electricimp.com/discussion/3924/new-aws-request-library
Has there been any progress on this? I am getting the same error when posting to Amazon DynamoDB. Although it is very inconsistent. Sometimes the request goes through just fine, but more often than not it returns error 35.
@darinpope couldn’t replicate the issue any more (seemed like maybe there was a change at the amazon end? We didn’t change anything at ours…)
What header type are you using for the dynamoDB post? If it’s not our V4 library, can you try that and see if it’s happier?
Do you mean the content-type header? If so I’m using Content-Type: “application/x-amz-json-1.1”
I’m using a modification of the code for your AWS V4 library. I needed to make some changes to get it to work for our system but its otherwise the same code.
Actually scratch that, the content-type is actually “application/x-amz-json-1.0”.
I tried using “application/x-amz-json-1.1” as is used in your AWS V4 library but that caused 404 errors.
Is there any way we can find out more about the error we are getting? The http response only has a statuscode 35. No body or headers with it. But looking up curl error 35 it sounds like there are many potential causes and there should be a message that could tell us more about the actual problem. Is there any way to see this message or any other debug information about the error?
There isn’t, but if you set up a repeated failure (ie keep doing an operation that causes this error) then email me your device ID, I can trace a connection and try to determine what is happening.
btw if you modified the V4 lib, can you tell us what you did (or do a pull request) so we can improve the library to take care of your needs?
Starting with random 35 and 404 response codes, I have altered the request() function so that SignedHeaders=host;x-amz-date;x-amz-target. Also, content-type must be “application/x-amz-json-1.0”.
The sample posts items to a DynamoDB table.
404 sounds rather strange; does retrying help? (ie 404 is absolutely at their end). We had a long support thread with AWS about the error 35’s and it does seem to be our end in that in some situation, gnuTLS gets confused and sends a corrupt header. AWS’s suggested workaround was to move to openSSL instead…
My sample works well with the alterations to the request() function (404 was caused by issues with headers on the DynamoDB PutItem request. I have seen several error 35’s returned when the agent is (re)started, but then a periodic PutItem every 10s consistently returns 200 
The 35’s do not re-appear after the first OK response, but I will continue testing.
35’s only appear when a connection is first set up, as it’s a TLS initiation error; when HTTP/1.1 reuses a connection, there’s no set up and hence no chance to get the error… which is probably why it’s relatively rare.
It appears that the 35’s will happen if the connection is ‘stale’.
In my agent, if I reduce the http POST to AWS DynamoDB to 10 minutes, the 35’s will re-appear on every attempt. I then retry every second, until eventual success in 1-10 retries. Because this will fuzzy the trend data a bit, I have settled on 1/minute POSTS which is frequent enough to avoid any 35’s after the initial re-start. Note that my agent receives reports every second-then accumulates, so that the agent itself is not getting ‘stale’.
Any progress on this? I’m getting the 35’s when POSTing a “PutItem” to DynamoDB. It works only with the changes to the “request” function suggested by @pkennaley (see above) and using http instead of https. When it works, the response is “200: {}”. Thanks.
We don’t really have a good repeatable test case at this point; I’m loathe to change TLS library as that comes with a lot more risk (we’ve used gnuTLS up until this point) but will if it becomes untenable.
For those people retrying the 35’s, how many attempts do you have to make before you get a success?
I’m also rather hoping that Amazon support TLS 1.2 on DynamoDB at some point…