support for Cisco ASR1000

[p-alik]

Hi, examples/get_system_information.pl doesn't work with

Cisco IOS XE Software, Version 03.13.03.S - Extended Support Release
Cisco IOS Software, ASR1000 Software (PPC_LINUX_IOSD-ADVIPSERVICESK9-M), Version 15.4(3)S3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2015 by Cisco Systems, Inc.
Compiled Thu 28-May-15 21:38 by mcpre

Execution without debug_level stayendless after password prompt, with debug_level=>1 it shows:

preparing to connect
[Net::Netconf::Access::ssh] Making SSH connection to '***'...
[Net::Netconf::Access::ssh] SSH connection succeeded!
[Net::Netconf::Access::ssh] Performing SSH authentication
[Net::Netconf::Access::ssh] Authentication succeeded!
[Net::Netconf::Access::ssh] Requesting SSH channel...
[Net::Netconf::Access::ssh] Successfully created SSH channel!
[Net::Netconf::Access::ssh] Starting subsystem 'netconf'...
[Net::Netconf::Access::ssh] Successfully started subsystem!
[Net::Netconf::Access::ssh] Will write 458 bytes to the SSH channel:
[Net::Netconf::Access::ssh] <hello>
  <capabilities>
    <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0#candidate</capability>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0#confirmed-commit</capability>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0#validate</capability>
  <capability>urn:ietf:params:xml:ns:netconf:base:1.0#url?protocol=http,ftp,file</capability>
  </capabilities>
</hello>
]]>]]>
[Net::Netconf::Access::ssh] Wrote 458 bytes (total written: 458).
[Net::Netconf::Access::ssh] Successfully wrote 458 bytes to SSH channel!
[Net::Netconf::Access::ssh] Reading XML response from Netconf server...
[Net::Netconf::Access::ssh] Read 604 bytes from SSH channel: '<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>urn:ietf:params:netconf:capability:url:1.0</capability><capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability><capability>urn:cisco:params:netconf:capability:notification:1.0</capability></capabilities><session-id>1112555144</session-id></hello>]]>]]>

[Net::Netconf::Access::ssh] Read 0 bytes from SSH channel: ''
[Net::Netconf::Access::ssh] Read 0 bytes from SSH channel: ''
[Net::Netconf::Access::ssh] Read 0 bytes from SSH channel: ''

It seems to be an Net::Netconf::Access::ssh issue.

Any advice for troubleshooting would be highly appreciated.

Sincerely yours, Alexei

[polettix]

There's an error looking for the frame terminator ]]>]]> that prevents proper reading of the responses. This commit should address it, although I cannot test it now and I'll try to PR later.

[p-alik]

Thank you for the reply, @polettix. I tested ce267c1. Unfortunately it doesn't work but the behavior is different: the script trapps in endless loop in Net::NetconfDevice->read_resp because it waiting for $endtag='rpc-reply' and never get it. Debug output:

[Net::Netconf::Access::ssh] Reading XML response from Netconf server...
[Net::Netconf::Access::ssh] Received XML response '<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>urn:ietf:params:netconf:capability:url:1.0</capability><capability>urn:cisco:params:netconf:capability:pi-data-model:1.0</capability><capability>urn:cisco:params:netconf:capability:notification:1.0</capability></capabilities><session-id>2924303360</session-id></hello>'

[polettix]

How can you say it's waiting for /rpc-reply instead of /hello? Judging from the conn_state member it's waiting to set to value Net::Netconf::Constants::NC_STATE_HELLO_RECVD, it should be waiting for hello actually.

Use of tag looking around might be a bit brittle if you ask me.

[p-alik]

How can you say it's waiting for /rpc-reply instead of /hello?

the request after saying hello is:

<rpc message-id='1'>
  <get-system-information/>
</rpc>

I'll run some tests next week.

[polettix]

Do you have the trace for that? (Note: I still have to test the change 🎱 )

[polettix]

Nevermind my last message... you did send the trace indeed :-D

Bottom line is I did the match but forgot to remove the hello message, so it stuck there. I'll send a correction shortly.

[polettix]

As anticipated, I forgot to do the removal of the previously extracted messages, so you continued to receive the hello tag over and over.

You can find what should work at this commit.

Just wondering whether there should be some code to cope with reception of unexpected strings though.

[p-alik]

9f6cade doesn't help :-( I'm afraid there is an other reason because the server always sends hello message and nothing more. See traces.tar.gz

[p-alik]

maybe there is some causality between this and #29 issues