-
Bug
-
Resolution: Done
-
Medium
-
El Alto Release, Frankfurt Release
-
Given current netconf client, invoke_rpc can be made to work provided that the user-supplied message-id parameter coincides with the auto-incremented message-id.
example:
This patch allows the user to label their message-id as they like and it will be overwritten to be consistent/unique inside netconf.
Given current netconf client, invoke_rpc can be made to work provided that the user-supplied message-id parameter coincides with the auto-incremented message-id. example: This patch allows the user to label their message-id as they like and it will be overwritten to be consistent/unique inside netconf.
-
Frankfurt Sp1: 11/4 - 11/22
Slightly convoluted issue, but it turns out that that message-id parameter should always be handled by the netconf client.
User-specified message-id in <rpc call is handled differently from other methods as it has the ability to specify a full <rpc .... xmlns="...." header to allow any vendor-specific RPC call.
Netconf client had an issue where the expected message id came from auto-incremented integer. Reply from device (<rpc-reply message-id="originalMessageId") , but netconf client was waiting to receive back a message with the message-id from the auto-incremented int. Within the given timeout, it never receives the ID it expects, hence invoke_rpc always returned an exception.
