- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Organization level 'uplinksLossAndLatency' endpoint returning TLS error information in its response
https://api.meraki.com/api/v1/organizations/15*****565/devices/uplinksLossAndLatency . One of our customers is trying to get performance data from this endpoint and getting errors like these in the responses.
We are looking for networkIDs and we are getting this
"networkId":"* TLSv1.3 (IN), TLS app data, [no content] (0):L_8134*********!234"
{"ts":"20* TLSv1.3 (IN), TLS app data, [no content] (0):
This is failing our collections . Question is if such data is expected in responses or Is it pointing out issues with the devices in play?
What would be a resolution for such errors ? Do we regex for expected data within responses or instruct the customers to verify the devices for TLS issues?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Noticed a similar behavior on other endpoints today.
Btw general notice , never post sensible info such as : MAC , IPs , location , serial number and network ids.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks . I edited my post. Any major changes or features got in recently ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'd just assume it's a transient failure, API endpoints are not 100% reliable/available.
You can always open a support case, always do this if a problem persists.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To add to what @RaphaelL mentioned regarding sensitive information, I'd include the Organization ID to that as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. Is this behavior due to the discontinuation of support for certain TLS versions on devices, which means fixing the versions on those devices ? Or just a transient failure that could be ignored ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't believe this to be due to TLS version compatibility as the TLS handshake wouldn't complete and thus wouldn't have an expectation any payload, partial or otherwise, would be delivered from the server. This can be easily verified in a Wireshark packet capture. Image attached illustrates this where the client sends an API request with TLSv1.1 and the server responds with a descriptive error followed by the termination of the TCP session.
