Running netconify --facts --telnet=x.x.x.x,yyy -u user -P mypass
25% of the time the session fails to terminate properly and is left in a never ending waiting, which is not ideal when validating 600 terminal server connections via ansible.
This issue seems to occur when nc.close() is called in tty.py, and I suspect that the issue lies somewhere in parsing the rpc response received. Probably due to login banners being present on the EX-4200's, which are messing things up when the rpc is made.
If however self.nc.close() is replaced with self._tty_close() which is a bit of a brutal way to force the session to close, this does actually appear to bypass the issue.
I also had issues with detecting the current state of the login as a consequence of login banners being present. The comment in tty.py for _ev_tty_nologin() , was helpful but did not resolve the issue entirely, and ultimately I needed to enable all three options.
In order for the state to be managed and finally lead to a login prompt. These changes in addition to the others, worked successfully with 600 terminal server port checks.
def logout(self):
"""
cleanly logout of the TTY
"""
self.notify('TTY', 'logging out ...')
self._tty_close()
return True
Running netconify --facts --telnet=x.x.x.x,yyy -u user -P mypass 25% of the time the session fails to terminate properly and is left in a never ending waiting, which is not ideal when validating 600 terminal server connections via ansible.
This issue seems to occur when nc.close() is called in tty.py, and I suspect that the issue lies somewhere in parsing the rpc response received. Probably due to login banners being present on the EX-4200's, which are messing things up when the rpc is made.
If however self.nc.close() is replaced with self._tty_close() which is a bit of a brutal way to force the session to close, this does actually appear to bypass the issue.
I also had issues with detecting the current state of the login as a consequence of login banners being present. The comment in tty.py for _ev_tty_nologin() , was helpful but did not resolve the issue entirely, and ultimately I needed to enable all three options.
In order for the state to be managed and finally lead to a login prompt. These changes in addition to the others, worked successfully with 600 terminal server port checks.
Regards, Andy asharp@juniper.net