November-16th-2020, 09:26 AM
Hi all,
the approach to calculate the MAC address from the CPU serial number and the Raspberry OUI would be a possibilty. But since we want to communicate with the Hilscher API anyway, we decided to read the MAC address from the API as well.
Here is a short explanation of how we could use the API. Maybe it helps someone who is facing a similar problem.
Our problem with the network settings request was that we not expected that the last part of the path "LANSettings" is case sensitiv.
And also the category parameter (?category=LAN) is mandatory.
This request now works:
Another problem we faced while integrating the API in our application was the login.
From the following request you could extract the retrieved authentication cookie:
The response status code is "302 - Found". This is a redirection status code, so the many high level HTTP frameworks follow the redirects by default.
But if you follow the redirects the authentication cookie is no longer valid.
If we use the following request for logging in (with the -L option), the retrieved cookie is not valid:
So we have to make sure, that the automatic following of redirects is disabled for the login.
Best regards,
Benjamin
the approach to calculate the MAC address from the CPU serial number and the Raspberry OUI would be a possibilty. But since we want to communicate with the Hilscher API anyway, we decided to read the MAC address from the API as well.
Here is a short explanation of how we could use the API. Maybe it helps someone who is facing a similar problem.
Our problem with the network settings request was that we not expected that the last part of the path "LANSettings" is case sensitiv.
And also the category parameter (?category=LAN) is mandatory.
This request now works:
Code:
curl -k -X GET 'https://<HOST>:443/get/networksettings/LANSettings?category=LAN' -H 'Cookie: <AUTH-COOKIE>'
Another problem we faced while integrating the API in our application was the login.
From the following request you could extract the retrieved authentication cookie:
Code:
curl -v -k -X POST 'https://<HOST>:443/login' -H 'Content-Type: application/json' -d '{"username":<USER>,"password":<PASSWORD>}'
But if you follow the redirects the authentication cookie is no longer valid.
If we use the following request for logging in (with the -L option), the retrieved cookie is not valid:
Code:
curl -L -v -k -X POST 'https://<HOST>:443/login' -H 'Content-Type: application/json' -d '{"username":<USER>,"password":<PASSWORD>}'
Best regards,
Benjamin