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.

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

Cisco timeout before Enable #9

Open
brycetryan opened this issue Apr 28, 2020 · 1 comment
Open

Cisco timeout before Enable #9

brycetryan opened this issue Apr 28, 2020 · 1 comment

Comments

@brycetryan
Copy link

Hi,

When running SSH into a Cisco device the connect() function in CiscoTrait tries to exec term width and term len. With a device that is locked down using enable, the term commands aren't available at this time, they're only available after enable mode is activated. Because the commands fail, the entire library fails to load and times out (at least in my environment).

In order to work around this, I have moved exec term width and len into a postEnable function in CiscoRouter, and have disabled postConnect as it has the same problem with exec('show ipv6'). This works perfectly, and the rest of the library functions as expected.

It would be nice for the exec function not to time everything out if the command wasn't recognised.

Thanks for your great work!

@ShaneMcC
Copy link
Owner

Hi,

Thanks for the feedback. I've not encountered devices where the term commands are locked behind enable, so I'll have a think about that.

The main reason for trying to get those done early is so that I don't need any -- More -- handling code then, and not everyone is likely to enable for everything they want (eg if the show commands they are running don't need it).

The show ipv6 check I probably should be more intelligent about in general.

It's not strictly needed everywhere, it's mostly to work around an insane bug on Sup720 devices where for some reason when you connect to them some vty sessions end up only having a subset of commands available to them not all commands. (The same commands available as if you had done routing-context someVRF) Notably, show ipv6 isn't there despite being in the global vrf context. My original fix of reconnecting until you get a working vty needs replacing with routing-context vrf global which fixes it.

Will have a think on all counts how to rework these post-connect checks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants