I have a cisco 3005 VPN Concentrator that came back from a site we shut
down. I have no passwords for this device. I am following CISCO's
password recovery doc, but I get no response in Hyperterminal from the
console port. I do not have the original cable that came with the
device, but I am using a standard RS232 cable. I have tried turing flow
control off (CISCO states to use hardware) and and that just causes
Hyperterminal to lockup. With flow control set to hardware I just get a
blinking cursor. Press enter twice and the cursor disappears for a few
seconds then comes back. Power cycling the VPN while connected does
nothing.  Any ideas?

[ Post a follow-up to this message ]

this.house.is.freakin.sweet@gmail.com writes:

>I have a cisco 3005 VPN Concentrator that came back from a site we shut
>down. I have no passwords for this device. I am following CISCO's
>password recovery doc, but I get no response in Hyperterminal from the
>console port. I do not have the original cable that came with the
>device, but I am using a standard RS232 cable.

I'm not the VPN guru here and don't have a copy of the cisco docs, but
have you considered the possibility that the cisco box is presenting
DTE at the async interface rather than DCE?  Try a null modem cable
and see what happens.

Joe Morris

[ Post a follow-up to this message ]

Thanks for the suggestion Joe.  Not real clear what you mean by null
modem.  I was using a DB-9 to DB-9 cable that came with an HP switch. I
also tried a cable set we bought that comes as RJ-45 to RJ-45 with
adapters to DB-9 and DB-25 (although the DB-25 doesnt apply here). Its
a flat cable similar to the DB-9 to RJ-45 that comes standard with
Cisco routers.  According to the cisco docs, it is a "standard" RS-232C
cable that plugs from the console port to a PC.  This is the purpose of
the HP cable, so I dont think it is a DTE/DCE issue, but I cant say
that with 100% confidence.

[ Post a follow-up to this message ]

"Ciscosis" <this.house.is.freakin.sweet@gmail.com> writes:

>Thanks for the suggestion Joe.  Not real clear what you mean by null
>modem.

A null modem cable swaps the input and output pins between ends.  Typically
this involves (from "A" end to "B" end):

DCD (1) --> DTR (4) and also to "A" end DSR (6)
Receive (2) --> Transmit (3)
Transmit (3) --> Recieve (2)
DTR (4) --> DCD (1) and DSR (6)
Ground (5) --> Ground (5)
DSR (6) --> DTR (4) and also to "A" end DCD (1)
RTS (7) --> CTS (8)
CTS (8) --> RTS (7)
RI (9) not connected

This allows two DTE devices to talk directly to each other.

>       I was using a DB-9 to DB-9 cable that came with an HP switch. I
>also tried a cable set we bought that comes as RJ-45 to RJ-45 with
>adapters to DB-9 and DB-25 (although the DB-25 doesnt apply here). Its
>a flat cable similar to the DB-9 to RJ-45 that comes standard with
>Cisco routers.  According to the cisco docs, it is a "standard" RS-232C
>cable that plugs from the console port to a PC.  This is the purpose of
>the HP cable, so I dont think it is a DTE/DCE issue, but I cant say
>that with 100% confidence.

Documentation has been known to occasionally <grin> have errors.  OTOH,
it might be right, and there isn't a DCE/DTE problem.  OTOH, whenever
I see an async interface in network server-side equipment I always
suspect DCE/DTE problems if the first attempts through a standard cable
(with various speed settings checked) fail.

Good luck.

Joe Morris

[ Post a follow-up to this message ]