1 post / 0 new
tthayer
My Milli Dev Kit not Seen by CoAP Get

Comment by Stephen McGregor [ 10/May/17 ]

Ok, using the poc.api.ssniot.cloud URL seems to have fixed the issue. I can see the responses from SFDP, and can see my devices listed. Can't test against Gateway at this point as I understand it's down for an upgrade.

Comment by Stephen McGregor [ 11/May/17 ]

With the Gateway back online, can confirm the process is working. Thanks all for the help.

[smcgregor@localhost Documents]$ echo $TOKEN | coap-client -m post -p 12345 -v 10 -T token1 -f - -t 0 "coap://api.coap-test.developer.ssni.com:5683/sessions"May 11 19:23:09 DEBG created endpoint 0.0.0.0:12345
v:1 t:CON c:POST i:fc05 {746f6b656e31} [ ]
May 11 19:23:09 DEBG sending CoAP request:
v:1 t:CON c:POST i:fc05 {746f6b656e31} [ Uri-Host:api.coap-test.developer.ssni.com, Uri-Path:sessions, Content-Format:text/plain ] :: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIvZGF0YSIsInN1YiI6IlROMDA0YTEwYTE5My1kMWY4LTRmYjUtODY3NC1kYTA0MWQwNTA4ZDciLCJzY29wZSI6ImFwaSIsImFjY2Vzc1BvbGljeSI6W3siQWN0aW9uIjoiZXhlY3V0ZS1hcGk6SW52b2tlIiwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6IiovYXBpL3NvbHV0aW9ucy8qIn0seyJBY3Rpb24iOiJleGVjdXRlLWFwaTpJbnZva2UiLCJFZmZlY3QiOiJEZW55IiwiUmVzb3VyY2UiOiIqL2FwaS90ZW5hbnRzLyoifV0sImp0aSI6ImY2MTY5MmI5LTA0N2UtNDEwYS1iMTUwLTk5MGMwNzJhNGVkNCIsImlhdCI6MTQ5NDQ5NDEwOCwiZXhwIjoxNDk0NDk3NzA4fQ.lrPTI5Pni10V0lvtBl-rdfcoOd8vuqUFip-QIajbDPg\x0A'
May 11 19:23:09 DEBG timeout is set to 90 seconds
May 11 19:23:09 DEBG received 10 bytes on fd 3
v:1 t:ACK c:2.01 i:fc05 {746f6b656e31} [ ]
May 11 19:23:09 DEBG *** removed transaction 6039
May 11 19:23:09 DEBG ** process incoming 2.01 response:
v:1 t:ACK c:2.01 i:fc05 {746f6b656e31} [ ]

Comment by Stephen McGregor [ 11/May/17 ]

Hmmm, maybe I spoke too soon. When I try to access one of my devices behind the gateway I get a 4.03 error:

[smcgregor@localhost Documents]$ echo $TOKEN | coap-client -m post -p 5683 -v 10 -T token1 -f - -t 0 "coap://api.coap-test.developer.ssni.com:5683/sessions"
May 11 21:27:32 DEBG created endpoint 0.0.0.0:5683
v:1 t:CON c:POST i:0b45 {746f6b656e31} [ ]
May 11 21:27:32 DEBG sending CoAP request:
v:1 t:CON c:POST i:0b45 {746f6b656e31} [ Uri-Host:api.coap-test.developer.ssni.com, Uri-Path:sessions, Content-Format:text/plain ] :: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIvZGF0YSIsInN1YiI6IlROMDA0YTEwYTE5My1kMWY4LTRmYjUtODY3NC1kYTA0MWQwNTA4ZDciLCJzY29wZSI6ImFwaSIsImFjY2Vzc1BvbGljeSI6W3siQWN0aW9uIjoiZXhlY3V0ZS1hcGk6SW52b2tlIiwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6IiovYXBpL3NvbHV0aW9ucy8qIn0seyJBY3Rpb24iOiJleGVjdXRlLWFwaTpJbnZva2UiLCJFZmZlY3QiOiJEZW55IiwiUmVzb3VyY2UiOiIqL2FwaS90ZW5hbnRzLyoifV0sImp0aSI6ImQ0YzQ3ZjkxLTY3MmQtNDNhOC05ODkzLTY2NGZmMTI1Yzk1NyIsImlhdCI6MTQ5NDUwMDUwNywiZXhwIjoxNDk0NTA0MTA3fQ.5GMg5MgoGac2-xlLF26JLYWGh5jQ5xyRVugVzR_b6eM\x0A'
May 11 21:27:32 DEBG timeout is set to 90 seconds
May 11 21:27:33 DEBG received 10 bytes on fd 3
v:1 t:ACK c:2.01 i:0b45 {746f6b656e31} [ ]
May 11 21:27:33 DEBG *** removed transaction 28845
May 11 21:27:33 DEBG ** process incoming 2.01 response:
v:1 t:ACK c:2.01 i:0b45 {746f6b656e31} [ ]

 
[smcgregor@localhost Documents]$ coap-client -v 10 -m get -p 5683 -P api.coap-test.developer.ssni.com:5683 coap://ssn001350050047db8e.shared-starfish-test-install.eng.ssnsgs.net:5683/.well-known/core
May 11 21:36:24 DEBG created endpoint 0.0.0.0:5683
v:1 t:CON c:GET i:1269 {} [ ]
May 11 21:36:24 DEBG sending CoAP request:
v:1 t:CON c:GET i:1269 {} [ Proxy-Uri:coap://ssn001350050047db8e.shared-starfish-test-install.eng.ssnsgs.net:5683/.well-known/core ]
May 11 21:36:24 DEBG timeout is set to 90 seconds
May 11 21:36:25 DEBG received 4 bytes on fd 3
v:1 t:ACK c:4.03 i:1269 {} [ ]
May 11 21:36:25 DEBG *** removed transaction 56750
May 11 21:36:25 DEBG ** process incoming 4.03 response:
v:1 t:ACK c:4.03 i:1269 {} [ ]
4.03

Comment by Stephen McGregor [ 11/May/17 ]

Can I get some help on the issue above, please? I'm following the instructions as listed on the portal (to the best of my ability), but as can been seen I'm getting an error.

Comment by Stephen McGregor [ 11/May/17 ]

Hi Todd Thayer, I think remove them again. Thanks.

Comment by Todd Thayer [ 11/May/17 ]

I just tested your same command with my clientid/secret and it works. Your ClientID is not valid for the the prod data platform. It is POC. This works:

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '

{"clientId": "4ae799b5-0a19-4957-a9be-ebadd7d1278d", "clientSecret": "XXXXXXXXXXXXXXXXXXXXXXXX"}

' 'https://poc.api.ssniot.cloud/api/tokens'

Comment by Stephen McGregor [ 11/May/17 ]

Hi Todd Thayer, my issue now is not getting the token; this works fine when run against poc.api.ssniot.cloud as you note.

The issue is getting a response from a device behind the gateway. When I do, I get either a 4.01 or a 4.03 error. The device is online, and is registered with my account.

Comment by Todd Thayer [ 11/May/17 ]

Can you paste your API call here?

Comment by Stephen McGregor [ 11/May/17 ]

Getting the token (works):

[smcgregor@localhost Documents]$ curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{"clientId": "86c9ffee-a54d-4b70-a309-b2a40c593e71", "clientSecret": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}' 'https://poc.api.ssniot.cloud/api/tokens'{"accessToken":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIvZGF0YSIsInN1YiI6IlROMDA0YTEwYTE5My1kMWY4LTRmYjUtODY3NC1kYTA0MWQwNTA4ZDciLCJzY29wZSI6ImFwaSIsImFjY2Vzc1BvbGljeSI6W3siQWN0aW9uIjoiZXhlY3V0ZS1hcGk6SW52b2tlIiwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6IiovYXBpL3NvbHV0aW9ucy8qIn0seyJBY3Rpb24iOiJleGVjdXRlLWFwaTpJbnZva2UiLCJFZmZlY3QiOiJEZW55IiwiUmVzb3VyY2UiOiIqL2FwaS90ZW5hbnRzLyoifV0sImp0aSI6IjczMTRjMWI0LTAzMDYtNDA4Zi04MTBmLWNlZGRjMzVhNzZiNyIsImlhdCI6MTQ5NDU2OTY1NCwiZXhwIjoxNDk0NTczMjU0fQ.TK2cH30ot-JaJ2Mm9n-IuXyc9kHu7fsUlwGf1ZKF5rc"}

Establishing a session with Gateway (works):

[smcgregor@localhost Documents]$ TOKEN=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIvZGF0YSIsInN1YiI6IlRJzY29wZSI6ImFwaSIsImFjY2Vzc1BvbGljeSI6W3siQWN0aW9uIjoiZXhlY3V0ZS1hcGk6SW52b2tlIiwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6IiovYXBpL3NvbHV0aW9ucy8qIn0seyJBY3Rpb24iOiJleGVjdXRlLWFwaTpJbnZva2UiLCJFZmZlY3QiOiJEZW55IiwiUmVzb3VyY2UiOiIqL2FwaS90ZW5hbnRzLyoifV0sImp0aSI6IjczMTRjMWI0LTAzMDYtNDA4Zi04MTBmLWNlZGRjMzVhNzZiNyIsImlhdCI6MTQ5NDU2OTY1NCwiZXhwIjoxNDk0NTczMjU0fQ.TK2cH30ot-JaJ2Mm9n-IuXyc9kHu7fsUlwGf1ZKF5rc

 
[smcgregor@localhost Documents]$ echo $TOKEN | coap-client -m post -p 5683 -v 10 -T token1 -f - -t 0 "coap://api.coap-test.developer.ssni.com:5683/sessions"May 12 16:19:20 DEBG created endpoint 0.0.0.0:5683
v:1 t:CON c:POST i:12d6 {746f6b656e31} [ ]
May 12 16:19:20 DEBG sending CoAP request:
v:1 t:CON c:POST i:12d6 {746f6b656e31} [ Uri-Host:api.coap-test.developer.ssni.com, Uri-Path:sessions, Content-Format:text/plain ] :: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiIvZGF0YSIsInN1YiI6IlROMDA0YTEwYTE5My1kMWY4LTRmYjUtODY3NC1kYTA0MWQwNTA4ZDciLCJzY29wZSI6ImFwaSIsImFjY2Vzc1BvbGljeSI6W3siQWN0aW9uIjoiZXhlY3V0ZS1hcGk6SW52b2tlIiwiRWZmZWN0IjoiQWxsb3ciLCJSZXNvdXJjZSI6IiovYXBpL3NvbHV0aW9ucy8qIn0seyJBY3Rpb24iOiJleGVjdXRlLWFwaTpJbnZva2UiLCJFZmZlY3QiOiJEZW55IiwiUmVzb3VyY2UiOiIqL2FwaS90ZW5hbnRzLyoifV0sImp0aSI6IjczMTRjMWI0LTAzMDYtNDA4Zi04MTBmLWNlZGRjMzVhNzZiNyIsImlhdCI6MTQ5NDU2OTY1NCwiZXhwIjoxNDk0NTczMjU0fQ.TK2cH30ot-JaJ2Mm9n-IuXyc9kHu7fsUlwGf1ZKF5rc\x0A'
May 12 16:19:20 DEBG timeout is set to 90 seconds
May 12 16:19:23 DEBG ** retransmission #1 of transaction 4822
May 12 16:19:23 DEBG received 10 bytes on fd 3
v:1 t:ACK c:2.01 i:12d6 {746f6b656e31} [ ]
May 12 16:19:23 DEBG *** removed transaction 18606
May 12 16:19:23 DEBG ** process incoming 2.01 response:
v:1 t:ACK c:2.01 i:12d6 {746f6b656e31} [ ]

Request to device behind gateway (fails):

[smcgregor@localhost Documents]$ coap-client -v 10 -m get -p 5683 -P api.coap-test.developer.ssni.com:5683 coap://SSN001350050047DB8E.shared-starfish-test-install.eng.ssnsgs.net:5683/.well-known/core
May 12 16:19:30 DEBG created endpoint 0.0.0.0:5683
v:1 t:CON c:GET i:d3ad {} [ ]
May 12 16:19:30 DEBG sending CoAP request:
v:1 t:CON c:GET i:d3ad {} [ Proxy-Uri:coap://SSN001350050047DB8E.shared-starfish-test-install.eng.ssnsgs.net:5683/.well-known/core ]
May 12 16:19:30 DEBG timeout is set to 90 seconds
May 12 16:19:33 DEBG ** retransmission #1 of transaction 54189
May 12 16:19:36 DEBG received 4 bytes on fd 3
v:1 t:ACK c:4.03 i:d3ad {} [ ]
May 12 16:19:36 DEBG *** removed transaction 41161
May 12 16:19:36 DEBG ** process incoming 4.03 response:
v:1 t:ACK c:4.03 i:d3ad {} [ ]
4.03

Comment by Todd Thayer [ 11/May/17 ]

looks like you established a session on port 12345 but then tried to communicate on port 5683 to the device (-p 12345 in first and -p 5683 in device get)

Comment by Stephen McGregor [ 11/May/17 ]

A history error. Please refer to the updated comment above that uses port 5683 for both.

Comment by Todd Thayer [ 11/May/17 ]

Mike I don't see anything wrong in his CoAP call below. Can you help?

Comment by Todd Thayer [ 11/May/17 ]

I don't have libcoap setup on my Windows PC and will take me a bit to configure. It is too late here and I am getting goofy. Hopefully Mike P can try running your calls to see if there is an issue. I don't see anything wrong though

Comment by Stephen McGregor [ 12/May/17 ]

I've also tried using Mike's Windows-based CoAP Client. It also fails, but appears to be timing out rather than getting a 4.01 or 4.03 message.

Comment by Todd Thayer [ 12/May/17 ]

Double check your devices in the portal and make sure the MACID's are properly fulfilled. Then get the devices from the data platform using the Studio API View UI and confirm proper provisioning.

Comment by Stephen McGregor [ 13/May/17 ]

Hi Todd Thayer, I've already checked that. Devices are shown as available on my account when using the /devices SPI on SFDP. Here's the relevant section returned (via Studio), showing the device in question (001350050047db8e):

{
  "devices": [
    {
      "deviceType": "MILLI",
      "domainInfo": {
        "nic_macID": "001350050047db8e"
      },
      "provisioningInfo": {
        "timeStamp": "2017-05-02 12:08:30.0",
        "profile": "Milli Developer Kit v1.0 with Arduino",
        "ssniMacAddress": "001350050047db8e",
        "ssniNetworkDeviceType": "MILLI",
        "status": "Provisioned"
      },
      "id": "017fc9f8-a07f-460c-9932-0dfdf580f6e4"
    },

Comment by Stephen McGregor [ 13/May/17 ]

Note, I'm now also seeing the 4.03 error message when attempting to do the same with Mike's Windows CoAP Client app.

2017-05-13 21:21:30,587 [10120] DEBUG DebugLog - Assembly name: HdkClient, Version=2.0.5.0, Culture=neutral, PublicKeyToken=null
2017-05-13 21:21:30,587 [10120] DEBUG DebugLog - Object returned: HdkClient.CoApGetGateway
2017-05-13 21:21:30,587 [10120] DEBUG DebugLog - About to send CoAP request
2017-05-13 21:21:30,587 [10120] DEBUG DebugLog - Version:1
 Type: NON
 Token : Length =6, Value=212130
 Code = 0.01 GET
 ID = 46071
 Uri-Host : SSN001350050047db8e.SHARED-STARFISH-TEST-INSTALL.ENG.SSNSGS.NET 
Uri-Port : 5683 
Uri-Path : .well-known 
Uri-Path : core 
Proxy-Scheme : coap 

 

 
2017-05-13 21:21:37,133 [12084] DEBUG DebugLog - Received response from server - token = 212130
2017-05-13 21:21:37,149 [12084] DEBUG DebugLog - Version:1
 Type: NON
 Token : Length =6, Value=212130
 Code = 4.03 Forbidden
 ID = 26

 
 Payload=

Comment by Todd Thayer [ 13/May/17 ]

MiniAP with MACID 001350030075c206 is provisioned twice on AssetID 104 105

Comment by Todd Thayer [ 13/May/17 ]

Given the fact that we can see other devices we are suspecting something about the way your devices are routing. I also can't seem to retrieve your tenantID on the network like the devices aren't provisioned on the network. A few thoughts:

1) Fix the double miniAP issue (press RMA and refulfill with proper macid)
2) Do you have the firmware posted to the portal at https://portal7-stage.mitangi.com/DocumentCenter#/ (instructions at https://portal7-stage.mitangi.com/how-update-firmware-images)
3) Get Mike Plisik to confiirm with ops that your miniAPs completed the call home process
4) Power all down, RMA all devices and refulfill which will reprovision, then put back on the network.

Comment by Stephen McGregor [ 14/May/17 ]

Hi Todd.
1) There are two mini APs, but they are different. They're not duplicates, but I see why it might appear they were. One's MAC ends in C206, the other in C20B.
2) Yes, the Milli is running the firmware posted on the portal. Given how quickly we get the "forbidden" response, it looks as though the request isn't getting through Gateway at all.
3) The Mini AP has definitely called home. It has all the appropriate Lua scripts, the tunnel is up and it's successfully sending DNS updates (both for itself, and also the Milli that's registering with it).
4) If I RMA the devices, who can I get to re-provision them? I assume as an end user that I can't do this?

I agree, it looks like it could be a provisioning issue, where Gateway isn't aware of the authorized devices.

Comment by Todd Thayer [ 14/May/17 ]

Sunny, Mike Plisik, Chieh-min, or myself can all fulfill for you at this time. If you want to initiate it I can re-fulfill. Are the MacID's all correct as currently displayed in the portal?

Comment by Stephen McGregor [ 14/May/17 ]

Hi Todd Thayer, I've RMA'd the milli and the mini AP it was communicating through. MAC IDs are 001350050047db8e (milli) and 001350030075c206 (mini AP).

Tenant ID per the RMA emails is TN004a10a193-d1f8-4fb5-8674-da041d0508d7.

Comment by Todd Thayer [ 14/May/17 ]

just fulfilled

Comment by Stephen McGregor [ 14/May/17 ]

Success!

2017-05-15 08:08:13,971 [1828] DEBUG DebugLog - Assembly name: HdkClient, Version=2.0.5.0, Culture=neutral, PublicKeyToken=null
2017-05-15 08:08:13,971 [1828] DEBUG DebugLog - Object returned: HdkClient.CoApGetGateway
2017-05-15 08:08:13,971 [1828] DEBUG DebugLog - About to send CoAP request
2017-05-15 08:08:13,971 [1828] DEBUG DebugLog - Version:1
 Type: NON
 Token : Length =6, Value=080813
 Code = 0.01 GET
 ID = 46071
 Uri-Host : SSN001350050047db8e.SHARED-STARFISH-TEST-INSTALL.ENG.SSNSGS.NET 
Uri-Port : 5683 
Uri-Path : time 
Proxy-Scheme : coap 

 

 
2017-05-15 08:08:24,587 [7000] DEBUG DebugLog - Received response from server - token = 080813
2017-05-15 08:08:24,607 [7000] DEBUG DebugLog - Version:1
 Type: NON
 Token : Length =6, Value=080813
 Code = 2.05 Content
 ID = 46071
 Content-Format : application/octet-stream 

 
 Payload=Y24213V

I'm still seeing 4.03 Forbidden when attempting to communicate with the other millis. Do you want to do some further troubleshooting on the remaining millis to identify how we got into this situation in the first place (and thus hopefully avoid a repeat)?

Comment by Todd Thayer [ 14/May/17 ]

No, so much has changed both on the portal side and new backoffice software. I suspect bugs have been fixed. I say RMA the rest.