Console not responding ProCurve 2650 switch

[Eric_355]

change the baud rate on the switch to 57600.
Using this command : "console baud-rate 57600".
I change the settings in telnet to reflect the 57600 baud-rate. It connects then immediately hangs and telnet becomes unresponsive. I then went to device manager and changes the com port settings on the pc to the 57600 baud-rate and still the same problem. I tried to reset the switch three times to get it back to the factory settings but I believe that the baud settings remain at 57600. Any suggestions???

[André Beck]

Hi,

probably not of help in your case, but I am under the impression that ProCurve switches do have a general problem with their serial console port. Almost every time I go to a switch deployed somewhere on a campus and running for some time, connecting the cable and starting the terminal program leads to nothing but a mute console, independendly of what settings are in use or how long I hammer the CR key. The cabling and terminal program are perfectly working, as a power cycle to the switch will show all the POST stuff and after the boot the CLI is available again. I first thought that was due to the ussual Windows sillyness an Hyperterm breakage, but it since happened to me a lot of times on my Linux/minicom laptop as well, so it seems to be more general. And no, of course my terminal program has hardware and software flow control set to off.

Do you anything when the switch boots, even if it is hosed due to a bitrate mismatch?

Andre.

[Jeff Brownell]

try setting the terminal emulator(s) for serial and telnet to the same speed you set the switch to. by default the console setting is "speed sense" which should auto match your term emulator. If the issue is outside of this, i recommend you open a support call...

[Mike Satterfield]

I've only used the factory baud-rate of 9600 on the 2600 series. The only problem I've experienced with the Procurve series 5300 / 2600 is that if you do no logout and disconnect from the console properly, you are forced into one of two options 1) reboot the switch or 2) use an IP based connection with telnet. For whatever reason, this generation of switches does not like the console connection being disconnected without grace.

Once logged in using telnet, it agrees with having the console session killed. You wouldn't be able to tell by doing a session list as the console session is always listed. After a kill on session one, you can again use HyperTerminal to access the console. This procedure is an alternative to rebooting the switch.