Login Failed, Bad Password

Do you have any special characters in your banner or prompt, such as a #, >, or $?  I've experienced this weirdness when my prompt ended in a $. 

I recommend contacting SolarWinds support for assistance on troubleshooting the issue.  Support will need the following information to help determine how Cirrus is trying to communicate with the device and how the device is responding.

1. A session trace.  The session tracing settings are available under File->Settings->Advanced->Session Tracing.
2. The Device Command Template value for the selected device.  This is viewable by double-clicking on the device and moving to the Communication section. 
3. The System OID.  This is viewable by double-clicking on the device and moving to the Discovered Properties section. 
4. Screenshots of the login screen, the screen after you type the username, the screen after you type the password, the screen after you type enable, and the screen after you type the enable password.  (This information will help support to see how the prompts are configured for the device at the various stages) 

Simply zip the files together and submit a ticket at https://forms.netsuite.com/app/site/crm/externalcasepage.nl?compid=638609&formid=12&h=3d0552f20b2e9bd6580b. 

My administrator setup a privilege 15 user and when i "validate login" i see that the username and password are entered by Cirrus and it reaches the # prompt  (that of an administrator). The process goes on and timeout with the above error. i have doen the same thing on an older Cisco switch and it works perfectly.

thanks

rod

I had the same problem. It ended up being the weird character thing like bleearg13 said

"Do you have any special characters in your banner or prompt, such as a #, >, or $?  I've experienced this weirdness when my prompt ended in a $."

I cleared out my banner and the login worked.

MT 

 Thanks so much for posting this. Our Cirrus 4.0 installation (Win2003server) is behaving the exact same way when using Telnet to devices.  We are a Cisco shop and this happens to random devices on every execution.  We noticed the problem when we set up a report to let us know which devices did NOT have the "Login OK" on the Login Status field. The goal being to report every morning on devices that dont have TACACS configured (since Cirrus uses a TACACS account).  This then includes devices with "Login failed: bad password", "Cannot login to device:  bad password", etc, but a lot of them just had the "Login Status" field blank (concerning of itself). 

Just like the original poster stated,  it is always a new set of random devices that Cirrus fails to login to, even devices on the SAME LAN as Solarwinds! (thus eliminating connectivity issues, which has its own way of being reported anyhow).   Anyway, I reported this to Solarwinds Support a week ago or so.    I wont bore you with the painful thread of back and forth emails until the issue got proper recognition, but after a complete re-install of Cirrus when it was proven that the problem was randomly consistently repeatable (if such a thing exists) they created two tickets allegedly with the Developers (tickets # 1178, and 1179) to fix this issue. One ticket is for the Telnet issue, the other is for Database flickering (totally separate issue where Cirrus cycles through database connections, including a No Database one, before coming back to the database its supposed to be using). 

You know, on an editorial note, I sure hope they fix this ASAP.  Support lost my templates, scheduled jobs, custom reports, now I have to do this all over again for our Non-Cisco devices.  The manpages/manual/admin guide is very vague about how to configure non-Cisco devices with different prompts, so this is going to take me HOURS, HOURS, HOURS of testing.  I followed the instructions for a device with really weird prompts, and Cirrus just kinda hung and wouldn't see the prompts.  I dont get it, and I am kinda upset that Support lost all my work.  BUT,  I just hope these efforts will help to get the Telnet/Login issue fixed for ALL DEVICES,  at least it would have been worth it. I'll keep my fingers crossed they get the right talented developer on this issue because IMHO this is a make or break issue for the Cirrus application. 

 Also, for everyone's reference regarding the Failed Login problem, here are at least 4 threads I found on the same topic here in Thwack of others experiencing a similar issue:

Seeing as these are all relativley old threads, I presume the interested parties either:

A) got their problem solved offline, silently, or through private messages, without ever updating their orginial threads with the solution. (deadbeats!)

or

B) got fed up and threw out all the devices that weren't supported fully (expensive!!)

or

C) moved on  to another CMDB solution that actually worked.

 I also checked the support knowledge base, hoping to find the solution listed there.  However, it was unable to locate any articles containing the terms "prompt" or  "Login" .  To be fair though, it also failed to produce results for  "Cirrus" "config" "cisco" nor even "to" or  "and", or anything else for that matter.

After  fully re-installing Cirrus 3 times with support,  after losing my configs at least once, after going through all the standard level-1 support you have to go through,  I finally got escalated to someone  in support that understood what I was talking about, and agreed it was Cirrus causing the issue and not me.    I worked with these folks for a few weeks.  They seemed serious, and had me upload a bunch of log files, then they asked for trace files, and more trace files.  I did this for a while, and then they wanted more trace files and more work.  I was spending a LOT of time doing work FOR Solarwinds and not getting paid, or even earning a discount on the Cirrus software, there were no incentives to continue spending time and my bosses were like "does this stuff work yet?", "why did we pay for this", I was getting a lot of grief at work.  I finally had to give up because it was taking too much of my time and we were getting nowhere.   It was more effective to look at alternative solutions.   I did not hear back from support about what they were doing to fix it, nor about a definition/cause for the problem,  and I dont believe any patches were ever released (that I know of).   I think this is a HUGE issue with this software. 

 It's disappointing that Solarwinds does not own up to this extremely critical and fundamental problem with Cirrus.   It just seems to have been swept under the rug, no mention of it anywhere.   I wish Solarwinds would list it as a clear and obvious KNOWN BUG, and what they are doing to fix it, and do Q/A on this before releasing the new version to the public (if there is one forthcoming, I have no idea).  Sorry to be so glum, just bummed out that it's been half a year (or more) and they still have not fixed a MAJOR FUNDAMENTAL problem with this software, nor even acknowledged it.

First of all, I want to also clarify that we have literally thousands of customers using Cirrus that are not experiencing this issue.  We're continuing to work with all customers that are reporting failure of random device downloads during nightly config backups. 

The problem is we have not been able to successfully reproduce in house, which makes it very difficult to isolate the exact cause and provide specific resolution.  It also makes it difficult to claim this as an obvious and known bug, when the problem is only reproducible with a handful of customers.  

This is why we've need your continued support and patienace as we work with you to gather logs, session traces, and try different things to troubleshoot this issue.  We are extremely committed to getting to the bottom of this issue, but cannot make any further progress if you are unable to work with us to troubleshoot any longer.  

If you're still interested in working with us, we'd be happy to send you an updated build and a new Telnet/SSH dll that you can try in your environment.  Please let us know how you'd like to proceed.

1) Because the issue is random and unrepeatable,  is it possible that other Network Admins just dont notice it, overlook it, or are completely clueless?  Do you really think they ALL know what they're doing?  You have to really know how to look for the failure among the many many successful connects,  it is not easy to see the issue in the first place, and it's easier to assume it was a bad T1, or some other failure.    Even for those of us who are programmers and have worked with languages that do similar functions like TCL-Expect, it's very difficult to finally see that the issue is indeed with the Telnet dll.  It takes a lot of  testing because when you re-try the same device it will work the second time (you cannot replicate the issue, EVER, remember?).  Saying that "thousands of customers using Cirrus that are not experiencing this issue" is a cop-out, IMHO.

2) If Solarwinds has an updated Telnet/SSH dll why isn't it on the Cirrus website, update page, or here on Thwack, why isn't it boldly mentioned on the Thwack Cirrus list, and on the several different threads under different subjects that reference this very problem?    If there is an updated Telnet/SSH dll, would you mind posting it here on Thwack for all of us to try? 

Believe me, I spent enough time on this issue and I see it every day on our Cirrus logs:  this is a MAJOR problem with Cirrus.  It is real, every day new devices fail, the same ones that worked the day before.  It is not a problem with us the client, our network, our server, etc. as support wanted it to be.   Support went through all of that already, we tested locally with devices on the LAN, even re-installed Cirrus on my system a few times and losing all the configs at least once.   It is a problem with the parser, what it expects back from the device, and how it "reads" these returns.     There are enough knowledgable customers seeing the same issue to prove that indeed it is a Solarwinds problem.   If Solarwinds cannot replicate the issue, then perhaps it is a Solarwinds QA issue.  But burrying the head in the sand saying that "no one else has seen the problem" is not responsible nor thorough, IMO.  Me and a lot of other people on this list see this issue everey day on our Cirrus logs. If Solarwinds would offer our company a discount or an incentive to work with your programmers to fix a Solarwinds issue I think our management would approve our spending time on this.  Short of that,  all I can do is point to the problem and beg, pray, whine with hopes that Solarwinds programmers will see the issue (and care enough about the integrity of the Cirrus product) to fix it.

I don't think the continuous intermittent failure with config backup is pervasive, because I've personally interviewed a great many of our Cirrus customers (magnitudes more than the number that are experiencing this particular issue).  Believe me, they're not a quiet bunch and would let me know if the solution isn't doing the most basic of its intended purpose (backing up configs).   So please don't construe my statement as a cop out, but more of an encouragement to you to not give up yet as the reality is there are many customers that are having success with Cirrus.  Most would say they even love Cirrus ;-)

I know you're obviously not there yet, but we're absolutely willing and committed to continue to work with you and any others experiencing this issue to bring it resolution. 

Here's what I would suggest as possible options/next steps for you given our current predicament (we don't have a fix, and you can't expend any more time or energy to work with us to find a fix):

1) Try reducing the number of simultaneous sessions - from 10 to maybe 3 or 4 (File > Settings > Configs > Config Transfers).  We've seen this resolve the issue for some customers.   This obviously is a TEMPORARY fix and this will slow down your total download time, but this is the only workaround we've got right now.  Just to be very clear, we realize this is not the permanent fix, we're not satisifed with this answer, and we will continue working towards a permanent solution.

2) Assuming you're still active on your maintenance, upgrade to 5.0 when it is released on 9/29.  This is the new build to which I was referring in my previous post.  This way your management won't give you a hard time since you're not helping us, but upgrading to the latest version of the software.  You can show management all the cool new things you get with 5.0 for free (e.g. new website).  I can't say this will fix your specific issue, but we've resolved a lot of other customers issues related to transfers in this release so it's worth a shot.

3) Wait until we fix the intermittent download issue based on our work with the other customers experiencing the issue.  We're planning on sending out the new (read: prototype) Telnet/SSH dll to those customers next week.  You'll be notified as soon as there is a permanent fix.