REST API Issues (Timestamps maybe?)

[Jive Jessie Morris]

I have my STUN server configured like so:

lt-cred-mech=true

realm=stun.example.com
fingerprint=true
use-auth-secret=true


sql-userdb="host=localhost dbname=turnserver user=turnserver password=pw connect_timeout=15"

Inside my database I have the following:

turn_secret:

4292c4ff6525fa51f0a030c67bdb0c5b2243f3de911deecef7f4e81cd1c406329df8c00bcc2858f0864451ff42f6c350dbd543a287d2d5e797bf346e0943455ce78d03cca08f439520f3942ff93fb5a81495f8760f498d055b3af79c9e78f20b02e069a0f563bed590f5d65051aeeeadc6d329110e307f3b776d16aa71a58b37




turnusers_lt:
                         name | hmackey
 1389151598:user1389150998598 | 77JEnMMmBwZSIMYnkqQQUuNhCjI=
 1389239138:user1389152738122 | SV4QjpIOOC03fqGN7jmEzvoWJS4=

When I run the command

turnutils_uclient -tv -r stun.example.com -u 1389239138:user1389152738122 -W SV4QjpIOOC03fqGN7jmEzvoWJS4= 127.0.0.1

I get

0: IPv4. Connected to: 127.0.0.1:3478
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: allocate sent
0: allocate response received:
0: Cannot complete Allocation
0: ERROR: Cannot complete Allocation

In my turn server's log I get a bunch of:

9: check_stun_auth: Cannot find credentials of user <1389162982:1389239138:user1389152738122>

I cannot for the life of me figure out how to craft my DB rows and request to get it to work. It seems like the server is to looking up the correct use (note the extra timestamp in front in the log output).

I'm using rfc5766-turn-server version 3.2.1.1. What am I doing wrong? I've read the Draft RFC about 1000 times. I'm generating the username by doing the HMAC-SHA1 with the body being "timestamp:username" and the key being my shared secret.

Thoughts?

[Oleg Moskalenko]

Looking at the provided data, I am not sure that I understand what you are trying to achieve. I assume that you are trying to test the WebRTC TURN REST API with the turnutils_uclient. If so, you are doing that incorrectly.

I see many errors in the configuration. Everything is explained in the wiki and the man pages. Did you read them ?

Did you examine the content of the examples/scripts/restapi subdirectory ?

Just a few of the errors:

1) You are using REST API, right ? Then you do not need the table turnusers_lt. For the REST API, you need only turn_secret table.

2) Why is the content of the turn_secret is so strange ? It must be just the plain secret string.

3) What is "-r stun.example.com" in turnutils_uclient command line ? Option -r means the port number in the test client.

4) Why the username is so strange in the test client command line ? It must be just the plain username, the test client will add the timestamp to it. See the examples/scripts/restapi subdirectory.

5) The -W parameter in the test client is probably not what you want. It must be the same as the content of the turn_secret table.

You so overcomplicated everything.

Regards,
Oleg

[Jessie A. Morris]

Okay,

After messing around with it a little this morning I discovered my problem. I did not realize the -W was for the shared secret. If I replace the -W with a -w it works correctly (as I would imagine).

Since there’s a username/password in the DB for that user/password combo, it works more or less as expected.

Now, as for a few of the other questions you had:

1) Yes, I am using the REST API. If only the turn_secret table is needed, where does the username generated in section 2.2 of the DRAFT API come into play? After playing around with this a little bit more, it appears as though it should more or less never get inserted into the database. It is generated on the REST server and stored no where (unless I want to store it for my own purposes), and then the client makes a request with that username/password combo. The TURN server then checks the signature to make sure it’s legit, and if it is the username/password combo is considered “good”.

2) My shared secret is really long. That’s all there is to it.

3) Sorry, that was a mistake. I didn’t have that in there until just before I sent the email. I thought -r was realm for a moment there.

4) Username is odd because it’s generated quasi-randomly currently. While we do want authentication, we don’t want to have to tie the TURN username to the user’s actual username currently.

5) This was the source of all of my issues, I do believe. I did not realize that the -W was the shared secret. Changing -W to -w got it working.

After reading your comments and sleeping on it, I think I have a better idea of what’s going on now. I think I’ll post my REST API up on GitHub and make a blog post about integrating it with the rfc5766-turn-server.

Thanks Oleg!

-- 
Jessie A. Morris
Sent with Airmail

--
You received this message because you are subscribed to a topic in the Google Groups "TURN Server project rfc5766-turn-server" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/turn-server-project-rfc5766-turn-server/gF3W4RM9rGs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/groups/opt_out.