Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unable to load configuration in zeroized device via telnet to console port #44

Open
Jainpriyal opened this issue Apr 7, 2016 · 8 comments
Open

Unable to load configuration in zeroized device via telnet to console port #44

Jainpriyal opened this issue Apr 7, 2016 · 8 comments

Comments

@Jainpriyal
Copy link
Contributor

I am trying to load config file to device at zeroized state via console port.
But it is getting hanged after starting netconf...

(venv)sh-3.2# netconify --telnet=host_console.englab.juniper.net,17035 -f file.config -u demo-P demo123
TTY:login:connecting to TTY:iec-en-pod4-vhost6.englab.juniper.net:17035 ...
TTY:login:logging in ...
TTY:login_warn:waiting on TTY.
TTY:login:starting NETCONF


^CTraceback (most recent call last):
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/bin/netconify", line 6, in <module>
    results = nc.run()
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/lib/python2.7/site-packages/netconify/cmdo.py", line 223, in run
    self._tty_login()
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/lib/python2.7/site-packages/netconify/cmdo.py", line 301, in _tty_login
    self._tty.login(notify=notify)
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/lib/python2.7/site-packages/netconify/tty.py", line 106, in login
    self.nc.open(at_shell=self.at_shell)
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/lib/python2.7/site-packages/netconify/tty_netconf.py", line 44, in open
    line = self._tty.read()
  File "/Users/jpriyal/Desktop/developement/netconify_pyEz/venv/lib/python2.7/site-packages/netconify/tty_telnet.py", line 74, in read
    return self._tn.read_until('\n', self.EXPECT_TIMEOUT)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/telnetlib.py", line 296, in read_until
    return self._read_until_with_select(match, timeout)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/telnetlib.py", line 364, in _read_until_with_select
    while not self.eof and select.select(*s_args) == s_reply:
KeyboardInterrupt
(venv)sh-3.2#
@jeffbrl
Copy link

jeffbrl commented Jun 22, 2016

@Jainpriyal I am encountering a similar problem with pushing a config to a zeroized vRR using an ESXi networked serial port. I want to make sure I understand what you are trying to do. A zeroized device will be in amnesiac mode and won't have a demo user.

Did you do some minimal configuration before executing netconify?

What do you see if you add --verbose 1 or --verbose 2?

@stacywsmith
Copy link

@Jainpriyal @jeffbrl

Can you connect and watch the console of the device?

If the device is logging anything to the console, then it disrupts the NETCONF session. If the device is trying to perform ZTP, I find that it often logs messages to the console.

@jeffbrl
Copy link

jeffbrl commented Jun 24, 2016

@stacywsmith I'm not sure what you mean. How would I do that if netconify is using the serial port? The vRR is zeroized.

I can see that the program connects successfully as root.

jeffl@ubuntu:~$ netconify --verbose 1 --telnet=192.168.0.150,7123 -f s4-vrr.cfg
TTY:connecting to TTY:192.168.0.150:7123 ...
TTY busy:checking back in 2 ...
TTY:logging in ...

DEBUG:current state:0
DEBUG:login:IN:login:`

Amnesiac (ttyd0)

login: `
DEBUG:password:
DEBUG:attempt:0

DEBUG:current state:2
DEBUG:login:IN:shell:`▒%`
DEBUG:password:
DEBUG:attempt:1
TTY: OK ... starting NETCONF

If I launch the netconf session manually and send an RPC, I am unable to type anything including a carriage return. I used the telnet escape sequence to exit. I am wondering if this might be the problem.

jeffl@ubuntu:~$ telnet 192.168.0.150 7123
Trying 192.168.0.150...
Connected to 192.168.0.150.
Escape character is '^]'.


Amnesiac (ttyd0)

login: root

--- JUNOS 14.2R4-S4 built 2016-02-12 13:06:52 UTC
% xml-mode netconf need-trailer
<!-- No zombies were killed during the creation of this user interface -->
<!-- user root, class super-user -->
<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:candidate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file</capability>
    <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability>
    <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability>
    <capability>http://xml.juniper.net/netconf/junos/1.0</capability>
    <capability>http://xml.juniper.net/dmi/system/1.0</capability>
  </capabilities>
  <session-id>1712</session-id>
</hello>
]]>]]>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/14.2R4/junos" message-id="1">
<software-information>
<host-name></host-name>
<product-model>vrr</product-model>
<product-name>vrr</product-name>
<package-information>
<name>junos-version</name>
<comment>Junos: 14.2R4-S4</comment>
</package-information>
<package-information>
<name>junos</name>
<comment>JUNOS Base OS boot [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jdocs</name>
<comment>JUNOS Online Documentation [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jcrypto64</name>
<comment>JUNOS Crypto Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jbase</name>
<comment>JUNOS Base OS Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jplatform</name>
<comment>JUNOS platform Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jkernel</name>
<comment>JUNOS 64-bit Kernel Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jroute</name>
<comment>JUNOS Routing Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jruntime64</name>
<comment>JUNOS 64-bit Runtime Software Suite [14.2R4-S4]</comment>
</package-information>
<package-information>
<name>jruntime</name>
<comment>JUNOS Runtime Software Suite [14.2R4-S4]</comment>
</package-information>
</software-information>
</rpc-reply>
]]>]]>

telnet> quit
Connection closed.
jeffl@ubuntu:~$

I'm using an ESXi networked serial port.

@stacywsmith
Copy link

@jeffbrl

I'm not sure what you mean. How would I do that if netconify is using the serial port?

Many terminal servers support simultaneous connections to the same port. In that case, you simply connect to the same serial port as netconify and "snoop" the communication.

I'm using an ESXi networked serial port.

Not sure if ESXi networked serial port allows simultaneous connections to the same port or not.

@jeffbrl
Copy link

jeffbrl commented Jun 27, 2016

I've attached a packet capture of the telnet session to the ESXI networked serial port. It looks as I'd expect until packet 8 in which my laptop sends a percentage sign to the vRR. After that, I'm not clear on why my laptop gets the xml-mode command back and then the program reads the login prompt again.

esxi networked serial port.zip

The output below matches the packet capture.

(venv)jeffl@ubuntu:~/development/netconify-testing/py-junos-netconify$ netconify --verbose 1 --telnet 192.168.0.150,7123 -f ~/s4-vrr.cfg
TTY:connecting to TTY:192.168.0.150:7123 ...
tty_telnet.py write()- content:


TTY:logging in ...
got[2]:

Amnesiac (ttyd0)

login:

DEBUG:current state:0
DEBUG:login:IN:login:`

Amnesiac (ttyd0)

login: `
DEBUG:password:
DEBUG:attempt:0
in _ev_login() - user is root
tty_telnet.py write()- content: root

got[2]: ▒%

DEBUG:current state:2
DEBUG:login:IN:shell:`▒%`
DEBUG:password:
DEBUG:attempt:1
in _ev_shell
TTY: OK ... starting NETCONF
tty_telnet.py write()- content: xml-mode netconf need-trailer

about to enter loop in tty_netconf.py open()
line: root

line: xml-mode netconf need-trailer

line: Password:
line:
line:
line:
line:
line:
^CTraceback (most recent call last):

@stacywsmith
Copy link

It appears both sides of the connection are echoing characters they receive.

The vrr sends a percent sign to the laptop in packet 5. The laptop echoes that percent sign back in packet 8.

The client sends "root" in packet 10 and the vrr echoes that back in packet 13.

The client sends "xml-mode netconf need-trailer" in packet 12, and the vrr echoes that back in packet 15.

The vrr also sends "Password:" in packet 15.

Bottom line is I'm not sure the ESXI networked serial port and the VRR are configured correctly. I suspect the echoing is causing the username to be interpreted as %. This is causing the device to prompt for a password for the % user.

@jeffbrl
Copy link

jeffbrl commented Jun 29, 2016

After researching, I see that packet 5 contains a telnet control command: FF(IAC) FD(DO) 25 (AUTHENTICATION). ASCII 0x25 is the percentage sign. The response in packet 8 is FF (IAC) FC(WONT) 25 (AUTHENTICATION). While this may not be the root cause of my issue, it seems like netconify should ignore telnet control commands like the pexpect module command does.

>>> child = pexpect.spawn("telnet 192.168.0.150 7123")
>>> child.sendline('\r')
2
>>> child.expect('login:')
0
>>> print(child.before)
Trying 192.168.0.150...

Connected to 192.168.0.150.
Escape character is '^]'.



Amnesiac (ttyd0)


>>>

Note: The ESXi's networked serial port requires a CR before displaying the login prompt. This is another potential reason for the error that I'm investigating.

@Jainpriyal Any chance you could post a packet capture? If my issue is differs from yours, I can open an issue that specifically tracks the problem with ESXi networked serial ports. Also, does your console require a CR to get the login prompt?

stacywsmith added a commit to stacywsmith/py-junos-netconify that referenced this issue Jun 29, 2016
@stacywsmith
Ignore Telnet options. Addresses issue Juniper#44.
731b83b 
If no option negotiation callback function is set, telnetlib
will pass Telnet options back to netconify in the data stream.
This is especially problematic for the AUTHENTICATION (0x25) option.
0x25 is an ASCII % character and confuses the login state machine into
thinking that it is at the shell prompt.
This function simply receives and ignores Telnet options. This prevents
the options from appearing in the data stream and confusing the
login state machine.
@stacywsmith stacywsmith mentioned this issue Jun 29, 2016
Open
@stacywsmith
Copy link

@Jainpriyal

Can you please try out my proposed fix?

sudo pip uninstall junos-netconify
sudo pip install git+https://github.com/stacywsmith/py-junos-netconify.git@ignore-telnet-options

@jeffbrl has confirmed it addresses his problem, but I'd like to confirm that your problem is really the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jeffbrl @Jainpriyal @stacywsmith