GET_RESP is adding a carriage return or some junk character in the err_msg field

[shanthakumarks]

When a GET is performed on an invalid Data model parameter from USP Controller , the USP Agent is responding back with the GET_RESP message with correct error code 7026 and error message "CheckPathProperties: Path (Device.BulkData.JunkValue3) does not exist in the schema" . But it is observed there is a carriage return is inserted at the end of error message which is causing parsing error at the USP Controller side.

Here is the example GET performed on an invalid Parameter "Device.BulkData.JunkValue3" . I have pasted the protobuf messages captured from USP Agent console logs.

/ # version: "1.0" to_id: "os::001A2A-JT3FFFDE8" from_id: "oui:84C8B1:0000" payload_security: PLAINTEXT mac_signature[0] sender_cert[0] no_session_context { payload[76] }

header { msg_id: "e8799508-c82d-4a3d-bec9-b71a2d7d6d4f" msg_type: GET } body { request { get { param_paths: "Device.BulkData.JunkValue3" max_depth: 0 } } }

DM_PRIV_GetNodeFromPath: Path is invalid: Device.BulkData.JunkValue3 CheckPathProperties: Path (Device.BulkData.JunkValue3) does not exist in the schema

version: "1.2" to_id: "oui:84C8B1:0000" from_id: "os::001A2A-JT3FFFDE8" payload_security: PLAINTEXT mac_signature[0] sender_cert[0] no_session_context { payload[169] }

header { msg_id: "e8799508-c82d-4a3d-bec9-b71a2d7d6d4f" msg_type: GET_RESP } body { response { get_resp { req_path_results { requested_path: "Device.BulkData.JunkValue3" err_code: 7026 err_msg: "CheckPathProperties: Path (Device.BulkData.JunkValue3) does not exist in the schema " } } } }

Here you can see the err_msg field is holding a carriage return at the end. err_msg: "CheckPathProperties: Path (Device.BulkData.JunkValue3) does not exist in the schema "

Suspecting this to be a bug in the USP Agent code.

[holme-r]

I'm unable to reproduce this on the latest OBUSPA. Are you using the latest OBUSPA, or has your team made any changes to OBUSPA which could have caused this ?

[shanthakumarks]

Thanks. We identified that our log_message_cb ( vendor specific function) was modifying the error message.