GCal3 with RPi running Stretch with openLuup

I’m having some trouble with GCal3 on an RPi running Stretch with openLuup. GCal3 works for me on openLuup with Jessie, but that was the 2.5a version. It seems to work until it makes the following curl request which responds with an ‘invalid request’ and then it fails.

any clues as to what might be wrong?

curl -v -k -s -H "Content-type: application/x-www-form-urlencoded" -X POST "https://accounts.google.com/o/oauth2/token" -d "grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion...

Can you clarify – what version of GCal are you using now and what does the log (with g_debug=3) give.

There is no reason why 2.5 on jessie and 2.5 on stretch should behave differently with a curl call – unless curl got changed dramatically (i.e. screwed up) in stretch. In latter versions of GCal - I replaced some of the curl calls, not because they did not work - but because there were better debug opportunities with alternatives.

The version is 2.5a. I’ll collect the logs. I don’t think the problem is with the curl specifically - I think there is something wrong with the values that are getting passed to that call. But I’m not sure what should be there, so I can’t tell where it is going wrong. I.e., what the jwt3 and jwt5 are supposed to be? Do you have sample of what it should look like, maybe for the test ID? Thanks.

I think I found the issue. The version of openssl installed wants: “openssl sha256 -sign …”, not “openssl sha -sha256 -sign …”

After that change it appears to be working.

Thanks – i’ll see if I can find out when that syntax changed and if I can use the different form based on the openssl version.

As an aside – jwt stands for java web token. Each use has a different value as it’s based, in part, on the time that the call is made.

Glad you got it working.

Question – when you checked the logs with the original form of the syntax. Was there an error that said “Error encoding jwt4”.

I’m thinking the easiest way to fix this is simply try the alternate syntax on an error condition.

As far as I can tell it did not log anything with ‘Error encoding’. It did pop this message out to the console:

Invalid command 'sha'; type "help" for a list.(I didn’t catch this initially because I ran a nohup on the openLoop_reload script with stderr going to a file which I didn’t think of looking in.)

It resulted in jwt4 being an empty string. Maybe check to see if the string is empty and then try the alternate? On the other hand it would be better to not have error messages popping up on the console or in the log each time this runs.

Here’s the log. I deleted most of the actual data. The thing that caught my eye was the ‘.’ at the end of the curl string. Just didn’t look correct and that’s why I went looking to see how the jwt is supposed to be formed.

2017-09-30 19:29:19.140 luup_log:11: GCal3 device: 11 - Checking for access-token 2017-09-30 19:29:19.140 luup_log:11: GCal3 device: 11 - local function: get_access_token 2017-09-30 19:29:19.140 luup_log:11: GCal3 device: 11 - Getting a new token 2017-09-30 19:29:19.140 luup_log:11: GCal3 device: 11 - local function: os_command 2017-09-30 19:29:19.140 luup_log:11: GCal3 device: 11 - Command was: echo -n '{***deleted***}' | openssl base64 -e 2017-09-30 19:29:19.156 luup_log:11: GCal3 device: 11 - local function: os_command 2017-09-30 19:29:19.156 luup_log:11: GCal3 device: 11 - Command was: echo -n ***deleted*** | openssl sha -sha256 -sign /etc/cmh-ludl/GCal3/GCal3js.pem | openssl base64 -e 2017-09-30 19:29:19.174 luup_log:11: GCal3 device: 11 - local function: os_command 2017-09-30 19:29:19.174 luup_log:11: GCal3 device: 11 - Command was: curl -k -s -H "Content-type: application/x-www-form-urlencoded" -X POST "https://accounts.google.com/o/oauth2/token" -d "grant_type=urn***deleted***l9." 2017-09-30 19:29:19.479 luup_log:11: GCal3 device: 11 - Returned Token: "{\n \"error\" : \"invalid_request\"\n}" 2017-09-30 19:29:19.480 luup_log:11: GCal3 device: 11 - missing access_token 2017-09-30 19:29:19.480 luup_log:11: GCal3 device: 11 - GC.access_token is: false 2017-09-30 19:29:19.480 luup_log:11: GCal3 device: 11 - GCV.CredentialCheck is false 2017-09-30 19:29:19.480 luup_log:11: GCal3 device: 11 - missing access_token 2017-09-30 19:29:19.480 luup.variable_set:11: 11.urn:srs-com:serviceId:GCalIII.gc_NextEventTime was: Credentials File Set now: missing access_token #hooks:

Thanks – I’ll take a look as soon as I can. I looked at two versions of openssl - one on my vera (OpenSSL 1.0.1 15 Jan 2015) and another on Lubuntu , stretch based I think (OpenSSL 1.0.2g 1 Mar 2016). The “help” gave the same command options for both. Next I will try (on my vera) the alternate syntax you identified and see what happens. It’s entirely possible that the long standing syntax was incorrect but worked …

You could also try “openssl dgst -sha256 …” - that seems like it is the more common form, but it would be good try it on the other versions and see if that works for them too.

I agree - using the digest form seems to be correct. Not sure where I got the other form from - was quite some time ago and it worked (until recently ;D ). I was unable to find any release notes as to what may have changed and when – so checking versions and etc is likely a poor approach.

I tried the form you suggested (openssl dgst -sha256) on two vera units running UI7: Edge and lite. Both worked just fine.

Assuming you are also using the digest form. I’ll push out a 2.7 beta and see what others experience.

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules