11-17-2009 02:24 PM
in the past we have had numerous successful password recoveries with VXworks and Linux based switches following the guidelines posted elsewhere.
Our latest addition, a set of Brocade 300s, though have turned out to behave a little different. First of all the serial port pinout is different from earlier on - "use the supplied cable" does not help much if you do not receive it.
For those wondering what cable they ought to use with one of those switches: a Sun/Cisco type "rollover" TP cable is needed. The cables used in all earlier switches - at least from 3200/3800 onwards are different and will not give any output.
This solved we faced the ever occurring task to tackle the passwords. Failing the standards we tried to use the "boot -s" method using the OSLoader string that has proven useful for all 200E/4100 switches we have had to revive.
The Brocade 300s do not enter single mode in the fashion reported before, hence no # prompt and consequently no manual mounting of dev/hda2 and also no access to passwddefault. The "-s" option is seemingly ignored and a "normal" boot process continues up to the login prompt.
Now... has anyone had to go through this and been successfull?
We do have access to the switch with the "user" account. The other accounts are locked with unknown passphrases.
Any and all ideas on how to boot into single user mode are very much appreciated.
And no.. I am not yet ready to send the recovery string out and part with more money
but for those who would like to know: 2AOdQdje/Io04TcsA6MVFw==
Thanks in advance to anyone willing to shed light into this "new" mystery.
11-17-2009 06:03 PM
this is the Boot Prom string, and not work for FOS Password reset.
the command passwddefault is a FOS command and not a Boot Prom Command.
--->>>....no # prompt and consequently no manual mounting of dev/hda2....
--->>>....boot process continues up to the login prompt.
that show to me as Hardware error.
11-17-2009 11:23 PM
thanks for explaing and trying to help. I had hopes that the Boot PROM string might magically know a way into the filesystem and let loose a password annihilate avalanche
As it seems it wouldn´t be of any help since what you fear is a hardware error is not - same happens on another 300 we have access to - some changes to the underlying Linux system, so it appears to me, have been made - maybe just a syntax change - and as usual not been documented for the poor guy who has got to find the lost keys
I spent quite a bit more time and guess I was lucky this time.
To me this procedure is novel but achieved only following documented FOS commands. So it may be of help to others in the same situation but unfortunately cannot be considered a surefire or failsafe method.
Success relies on the status of the fabric data distribution database policies set in the "locked" switch. One cannot know them but only hope for that all those have been left at "accept". The output in a switch will often be as such:
Local Switch Configuration for all Databases:-
DATABASE - Accept/Reject
SCC - accept
DCC - accept
PWD - accept
FCS - accept
AUTH - accept
IPFILTER - accept
Fabric Wide Consistency Policy:- ""
If PWD is set to "accept" and not to "reject" the following procedure that is very much the same as the one useful for the passwordreset utility that worked in older switches (not for the 300, bails out with message "-3") will unlock the password protected switch.
Cobble up a fabric as described before - remove all zoning from switch 1, set its Domain ID to something that doesn´t clash with the locked switch (you will need only one attempt to find out ;) and connect both switches via fibre. Webtools will show the second switch as a teaser - there won´t be any access though.
Now distribute the password database from the accessible switch to the inacccessible one using the following command:
distribute -p PWD -d *
The wildcard "*" will distribute the password database fabricwide and that´s all there is to it :D
My assumption is that the old passwordreset utility knows a way to do exactly the same maybe even with policies set to reject only it is no longer useful in the current 300 series.
The formerly locked switch is now open.
Still... I´d be a lot happier not to have to rely upon the former administrators negligence leaving the databases open for changes but rather know a 100% solution for the next ones to come.
Thanks for reading