Organization level 'uplinksLossAndLatency' endpoint returning TLS error information in its response

ag_scilo
Here to help

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? 

 

6 Replies 6
RaphaelL
Kind of a big deal
Kind of a big deal

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.

ag_scilo
Here to help

Thanks . I edited my post. Any major changes or features got in recently ?

sungod
Kind of a big deal

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.

 

JasonM
Meraki Employee
Meraki Employee

To add to what @RaphaelL mentioned regarding sensitive information, I'd include the Organization ID to that as well.

ag_scilo
Here to help

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 ?

JasonM
Meraki Employee
Meraki Employee

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.

Screenshot.png

 

Get notified when there are additional replies to this discussion.