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

[ag-scilo]

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?

[Raphael_L]

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]

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

[sungod]

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.

[JasonMo]

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

[ag-scilo]

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 ?

[JasonMo]

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.