PIX 501 telnet issue

[jakerutski]

Hello everyone-

I have a seemingly simple issue, and I have yet to find an answer. We utilize 18 PIX501 devices for each of our remote terminals.

Recently, I discovered that I cannot execute a successful 'show run' command from certain machines in our home office...and to make it more confusing, it only happens on a few of the PIXs.

All of the machines I have tried are either running Windows XP, 2000, or server 2003...I open a command prompt, telnet to the PIX and enter into the enable prompt with no problems whatsoever.

As soon as I type show run and press enter...the curser just stops, and all I see on the screen is:

User Access Verification

Password:

Type help or '?' for a list of available commands.

panama> en

Password: *************

panama# show run

And the curser just sits and blinks...on the same PIX, from a different machine, I get the config just fine...

Any help would be greatly appreciated. Thanks in advance!!

[trmccart]

Jake,

There is a software caveat on the PIX where a 'show run' will hang if there is another user on the PIX that has performed the same 'show run' but is at a 'more' prompt.

I think it is possible that a session could be 'left stranded'. Try upgrading or checking bug navigator.

Regards,

Troy

[jakerutski]

Thanks for the reply, Troy. I did check to see if there were any other sessions running...as well as rebooting the PIX just to be sure.

I don't know if it's related, but from the same machine that will hang on the show run, I couldn't do a 'show ?'...seems like anything that returns a great deal of lines.

If I set 'pager lines 24', then I'll get the 24 lines with a prompt...just fine. But when set to 'no pager' it just hangs.

[trmccart]

You are hitting a bug. The fix is in PIX 6.3.4 software. What version are you running?

I couldn't find the bug id but I did find a reference to corresponded to your exact symptoms.

~Troy

[jakerutski]

Thanks again, Troy.

We are currently running 6.3(5) on all of the PIX devices, including ones where it doesn't hang in the 'show run' on that machine.

User Access Verification

Password:

Type help or '?' for a list of available commands.

panama> en

Password: ***********

panama# show version

Cisco PIX Firewall Version 6.3(5)

Cisco PIX Device Manager Version 3.0(4)

Compiled on Thu 04-Aug-05 21:40 by morlee

[trmccart]

Jake,

Sorry not to been of much help. This does sound like a bug. I searched through over 1300 software caveats -- I couldn't find anything that fits your description.

Out of curiousity, do you get the same results if you use SSH instead of telnet?

If you would please, open a TAC case. If a TAC engineer can't find a DDTS (software caveat id) then they can capture enough information to file one.

Regards,

Troy

[jakerutski]

Well this weekend, I had a chance to get SSH going on one of the PIXs that would not return a running-config...unfortunately, even SSH has the same issue-

login as: pix

Sent username "pix"

pix@10.150.155.250's password:

Type help or '?' for a list of available commands.

panama>

panama> en

Password: ***********

panama# show run

And that's it- If I get a chance this afternoon, I will open a TAC case. Thanks again for all your help, Troy!

[Fernando_Meza]

I would suggest to use another terminal emulator such as putty.exe and test it in that way it could be an issue related to your telnet application ..

[jakerutski]

Thanks for the input Fernando. We've tried Putty, Hyperterminal, commandline telnet...

And another machine on the same subnet can pull it just fine. I'll try to set up SSH here this evening- see if that gets it.

Thanks for all your help!!

[KURT HILLIG]

This may or may not be related but I've run into an IOS bug that can produce similar symptoms.

If your client machine is too busy to accept the output from your show command it may reduce the TCP window size to throttle the rate at which the output is returned, and may set it to zero to suspend output entirely for a while. When this bug is present, then the far end device stops sending output even when the window size is set back to a non-zero value.

What made this tricky to track down is that "manual" telnet worked fine; this only showed up with an expect script that opened a telnet connection.

About the only way to tell if this is happening is to watch the telnet session with a sniffer and look at the packet headers at the time that it hangs.

Again, I don't know if this applies to your situation or not; but if you can run a sniffer to watch one of these sessions you might learn something useful...