Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible to get the Preshared Key? #11

Open
Joey-1970 opened this issue Feb 22, 2020 · 7 comments
Open

Possible to get the Preshared Key? #11

Joey-1970 opened this issue Feb 22, 2020 · 7 comments
Assignees
Labels
question Further information is requested

Comments

@Joey-1970
Copy link

Hello Glenn,

many thanks for your very good documentation and the examples!

Is it possible to get the Preshared Key for a given Username or to control if the Preshared Key for the given Username is still guilty?

Joachim

@glenndehaan glenndehaan added the question Further information is requested label Feb 24, 2020
@glenndehaan glenndehaan self-assigned this Feb 24, 2020
@glenndehaan
Copy link
Owner

Hi @Joey-1970,

As far as I can see it isn't possible to get the old Preshared Key for a given Username. You should just create a new one. This isn't a limitation from IKEA but from COAP.

As far as checking if a Preshared Key is still valid is also not really easy with the coap-client.
One trick I discovered is by using the verbose mode of the coap-client to check if the transmission of the command worked. After then decreasing the retry time you should be able to see that the key doesn't work.

The example command would be something like this:
coap-client -m get -u "$TF_USERNAME" -k "$TF_PRESHARED_KEY" "coaps://$TF_GATEWAYIP:5684/15001" -v 9 -B 10

If the key is invalid the following should happen:

Feb 24 08:49:59 DEBG created DTLS endpoint 0.0.0.0:45060
v:1 t:CON c:GET i:ac04 {} [ ]
Feb 24 08:49:59 DEBG sending CoAP request:
v:1 t:CON c:GET i:ac04 {} [ Uri-Path:15001 ]
Feb 24 08:49:59 DEBG *** new session 0x11a3430
Feb 24 08:49:59 DEBG call dtls_write
Feb 24 08:49:59 DEBG *** add 0x11a3a70 to sendqueue of session 0x11a3430
Feb 24 08:49:59 DEBG timeout is set to 10 seconds
Feb 24 08:50:04 DEBG ** retransmission #1 of transaction 44036
Feb 24 08:50:04 DEBG call dtls_write
Feb 24 08:50:04 DEBG ** retransmission #2 of transaction 44036
Feb 24 08:50:04 DEBG call dtls_write
Feb 24 08:50:09 DEBG ** retransmission #3 of transaction 44036
Feb 24 08:50:09 DEBG call dtls_write
Feb 24 08:50:19 DEBG ** retransmission #4 of transaction 44036
Feb 24 08:50:19 DEBG call dtls_write
Feb 24 08:50:39 DEBG ** removed transaction 21146
Feb 24 08:50:44 DEBG *** removed session 0x11a3430

I hope this answers your question.

@glenndehaan
Copy link
Owner

Woops I made one mistake in my previous comment. I was using the wrong IP. The output should be something like this:

Feb 24 09:01:26 DEBG created DTLS endpoint 0.0.0.0:32799
v:1 t:CON c:GET i:e158 {} [ ]
Feb 24 09:01:26 DEBG sending CoAP request:
v:1 t:CON c:GET i:e158 {} [ Uri-Path:15001 ]
Feb 24 09:01:26 DEBG *** new session 0x1e8d430
Feb 24 09:01:26 DEBG call dtls_write
Feb 24 09:01:26 DEBG *** add 0x1e8da70 to sendqueue of session 0x1e8d430
Feb 24 09:01:26 DEBG timeout is set to 10 seconds
Feb 24 09:01:26 DEBG received 60 bytes on fd 3
Feb 24 09:01:26 DEBG received 95 bytes on fd 3
Feb 24 09:01:26 DEBG received 25 bytes on fd 3
Feb 24 09:01:26 DEBG received 15 bytes on fd 3
Feb 24 09:01:26 INFO ** Alert: level 2, description 20
Feb 24 09:01:26 ALRT 20 invalidate peer
Feb 24 09:01:26 DEBG *** removed transaction 2962
Feb 24 09:01:26 DEBG *** EVENT: 0x0200
Feb 24 09:01:26 DEBG *** removed session 0x1e8d430
Feb 24 09:01:26 WARN received alert, peer has been invalidated

Note the: ALRT 20 invalidate peer. This means the key is invalid.
The example above is when an invalid IP/Port is given.

@Joey-1970
Copy link
Author

Hi Glenn,

Thank you very much for your suggestion. I will try it. I write a module for a software called IP-Symcon (https://github.com/Joey-1970/IPS2Tradfri).
With your very good documentation it work very fast and stable.
One of the open things is, what we write above with the key, it will maybe more code necessary to work with the key as the "normal" function... ;-)

The other question that keeps me busy is, how is the best way to know, when there are some changes maybe by remote or (another) app. Currently I have to poll the state in short intervals.
Is there any other (better) way? Some broadcast I can get from the Gateway?

Joachim

@glenndehaan
Copy link
Owner

Yeah thats the drawback of the COAP protocol. It isn't a real time protocol so polling will always be the solution for these problems. Even the IKEA app isn't realtime and is using a combination of polling + a refresh icon.

@Joey-1970
Copy link
Author

Hello Glenn,

thank you again, so I must polling - in my eyes not a very good way, but there is mayby in this moment no other way.

I try your suggestion to verified if the key is still valid, but it take nearly one minute to do it. Is there a other idea?

Joachim

@glenndehaan
Copy link
Owner

You should be able to control the break operation by setting the -B 10 parameter. By default it waits/retry's for 90 seconds. But you should be able to set this to like 5 seconds

@Jan21493
Copy link

@Joey-1970,
it's possible to register for an event to avoid polling. Maybe not with the coap-client, but e.g. node-red-contrib-ikea-tradfri such a technique is used. The IKEA home smart app is also using such an event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants