Net::Telnet perl scripting the ProCurve 25xx

[Todd Knauer]

We're about to put out a few thousand ProCurve 2512/2524 switches and we have several fatal issues with the ProCurve Manager software which causes us to have to write our own software (that would be me) to manage the switches. I won't go into why PCM will not work for us although I would be more than happy to if anyone is interested.

I plan on creating some web based software using Apache/PHP/MySQL/Linux (actually I may have to use Oracle instead of MySQL, not for technical reasons) and doing archiving and scheduled commands via Net::Telnet in Perl. What is the deal with these switches pumping out all this ANSI control character garbage? It really makes scripting a pain, not to mention screws up the rows/cols in a shell/console/terminal. Is there a setting in these switches that will make them behave like any other normal terminal device (i.e. so I don't have to work around all the ANSI codes)? It isn't going to be that big of a deal to filter it out but it is so annoying I have to think there is a way to turn it off. Any suggestions welcome. Thanks!

[Ralph Bean_2]

Todd -

Have you been able to deal with the TELNET login with perl? I chose to use an expect script to TELNET into a ProCuve switch and execute CLI commands. This allowed me to deal with the "interactive" login, and I did not have any problems with the VT-100 escape characters. If you decide to go that route I can post a short, shell expect script here that will get you started.

Alternatively, if your script uses the CLI you don't mind degrading the formatting of the menu user interface, use the configuration command:

console terminal none

There is an idiosyncracy with the backspace character in that the cursor does not correctly reflect the backspace. The backspace DOES work correctly, however.

Finally, it is possible that Hewlett-Packard may come out with an upgrade to the 'console terminal none' command during the next few months that will not have a side-effect on menu formatting.

Regards,
Ralph

[seymour999]

If you Setup the switches to come up in command-line mode, do you still get the control characters?
We use Kiwi CatTools to back up 2524s and it works OK (provided they're set as above).

[Todd Knauer]

Thanks for the tips. The "console terminal none" almost works but has the backspace issue as you mention (which shouldn't be a problem when scripting). I think that mode will be better for scripting but telneting in from a terminal the backspace thing will be a problem.

I know this is probably a bad word here but the Cisco routers and switches have no problem detecting the terminal capabilities when logging in and adjusting accordingly. In addition they are a breeze to script. If there were a mode that I could put the switch in to give me the exact same behavior life would be grand.

For instance, for interactive CLI I am usually running a bash shell in a terminal (konsole, gnome-terminal, xterm, etc). When I log in to any server, Cisco device, or many other CLI type of appliance device on our network the terminal capabilities are detected and adjusted accordingly on the device. For instance, if I have my terminal sized to 100x50 (I constantly vary the size of my terminals) the device should recognize that I my terminal is set to 50 rows. As I said, the "console terminal none" is much better, however if someone did then want to use the menu it would be nearly impossible. And having to change the option and reload is a pain (it seems to require a reload).

I think the problem is that someone is trying to make it "pretty" by sending screen clear and cursor positioning and that is fine for the menu but for CLI none of this should be done (IMO). Get rid of the cursor tricks and detect and set the rows properly and it will be a winner.

As far as the KiWi tools it looks like they are Windows based which counts them out for us (one of reasons we're not much interested in PCM, but not one of the main reasons). We currently have several thousand Cisco devices and use their management product called CiscoWorks for config archives, change detection, etc. And we use it to schedule changes in the routers and switches (we can schedule a set of commands to be run on a subset of switches for instance).

I have already written my own archiving utility for a set of devices that are not supported by CiscoWorks and I figured it would be an easy task to incorporate these HP switches. In fact the archiving part is rather simple and I can do this with Net::Telnet (or Expect, etc). The functionality that I now need to add is the ability to schedule ad hoc scripted commands on all or a subset of switches by network management/NOC people. I have not actually tried Expect on these particular switches so I guess I will do that today to see if I can more easily get around the VT100 formatting.

If only I could set the terminal type to "none" without requiring a reload, that would be something that could be added to the beginning of the script so the rest of the script is easier to code. Maybe that is the answer.

Thanks again for the tips!

[Todd Knauer]

After some more playing today I believe I will opt for the standard Perl IO::Socket::INET module rather than NET::Telnet or Expect. It's quite easy to script and seems to work well for both. I do have to do some s/blah//g stripping of "\r" when grabbing configs but for sending a batch of commands I think I can pretty much ignore the escape sequences, although I did a pretty good job of filtering them out in my earlier NET::Telnet tests.

I still wish the terminal capabilities were a little more standard for interactive use though. Thanks again!

[Domenico Viggiani]

Hi Ralph,
I have same problem (logging in with Net::Telnet). May you post EXPECT scripts to fetch configs?

Thank you

[Flaquito]

I know this is an old topic, but I had the same problem, so hopefully posting the solution will help someone else.

The command:

console local-terminal none

takes effect immediately, without requiring a switch reload. This removes all of the control characters.

Note that this command seems to apply to new sessions as well, so at the end of your script you probably want to issue the command:

console local-terminal vt100