I'd be surprised if Net::Telnet is having problems with escape sequences. On what are you basing that claim? If you can give some details, we may be able to help solve the problem. Show a little code and any error messages (or unexpected output) you're getting, and we can look things over.
...roboticus
When your only tool is a hammer, all problems look like your thumb.
| [reply] |
Regarding ANSI problems - see perldoc Net::Telnet:
When a TELNET server first accepts a connection, it must use the ASCII control characters carriage-return and line-feed to start a new line (see RFC854). A server like the "Microsoft Telnet Server" that doesn't do this, isn't a TELNET server. These servers send ANSI terminal escape sequences to position to a column on a subsequent line and to even position while writing characters that are adjacent to each other. Worse, when sending output these servers resend previously sent command output in a misguided attempt to display an entire terminal screen.
Connecting Net::Telnet to one of these false TELNET servers makes your job of parsing command output very difficult. It's better to replace a false TELNET server with a real TELNET server. The better TELNET servers for MS-Windows allow you to avoid the ANSI escapes by turning off something some of them call console mode.
It is possible to set the console mode manually on ProCurves and Net::Telnet works like a charm.
I am looking for someone who already automated Telnet access to ProCurves and who might give me a hint.
Regards,
| [reply] |
The unfortunate truth about "console mode" is that it really isn't the TELNET protocol, just as the docs for Net::Telnet say. There's a reason there are RFC and STD documents, and there's a reason responsible developers try to maintain compatibility with them.
HP, it seems, has not done so in their default configuration. I would suggest that you contact your equipment vendor for a fix to their issue, because that's where the trouble lies. If you get no satisfaction dealing with their nonstandard implementation, then perhaps you can get some software to deal with it. In any case, consider it a lesson learned about standards and shop for hardware that follows them next time if you are fortunate enough to have that sort of input in your organization.
In the meantime, have you tried just setting a delay in your program and using Net::Telnet to send the commands to disable the offending option "in the blind"? If you can issue the authentication, wait, issue the command to disable "console mode", wait, and issue the command to write the config (if there is one and this line doesn't use a persistent object -- I admit I've not used a lot of HP networking equipment), then maybe you can automatically get into a usable TELNET session in which you can reliably read prompts after that.
| [reply] |
You have find a solution with Net::Telnet and Procurve ?
| [reply] |