py-junos-eznc
py-junos-eznc copied to clipboard
RpcError exception is not raised when <rpc-error> element is not in the netconf namespace.
While the primary issue reported in #715 is a Junos bug, it did expose an issue with PyEZ. In #715, the response contains an <rpc-error>
element, but no RpcError
exception was raised.
Normally, ncclient raises an RPCError
exception when an <rpc-error>
tag is present in the response. PyEZ then catches this exception and raises its own RpcError
exception.
However, ncclient only raises an RPCError
exception when the <rpc-error>
element is in the urn:ietf:params:xml:ns:netconf:base:1.0
namespace.
In this case, the full response from the device is:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/16.1R4/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:2032f515-3f87-4bce-9fe7-747bdba60ca5">
<ping-results xmlns="http://xml.juniper.net/junos/16.1R4/junos-probe-tests">
<ping-failure>usage error</ping-failure>
<rpc-error>
<error-type>protocol</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<source-daemon>ping</source-daemon>
<error-message>
usage: ping [-ACNQRSXadfnqrvw] [-c count] [-i wait] [-g loose-gateway]
[-l preload] [-p pattern] [-s packetsize] [-t tos]
[-F source] [-G strict-gateway] [-I interface]
[-Ji|r|4|6|I interface|U routing-instance|L logical-router]
[-T ttl] host
</error-message>
</rpc-error>
</ping-results>
</rpc-reply>
The <rpc-error>
element does not contain an xmlns
attribute. Therefore, it inherits its namespace from an ancestor element. In this case, that's the http://xml.juniper.net/junos/16.1R4/junos-probe-tests
namespace from the <ping-results>
element. This causes ncclient not to recognize this as an error.
PyEZ should be enhanced to recognize this non-compliant Junos-specific situation and continue to raise an RpcError
exception in these cases.