[CSHARP-748] Unable to connect to replica set using random password containing numbers Created: 30/May/13  Updated: 05/Apr/16  Resolved: 20/Jun/14

Status: Closed
Project: C# Driver
Component/s: None
Affects Version/s: 1.8.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chris Robison Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

3 node replica set each running RHEL. One node is an 8 hour delay.



 Description   

I'm actually sure where to report this since I'm not completely sure if this is a driver problem. In our production environment, we are connecting to one particular database using a database user. The username is pretty simple and the password is a random string of upper/lowercase letters and numbers. When specifying all three nodes in the connection string and using a password that contains numbers we keep getting a timeout exception from the driver. The logs on the mongo server repeated report a key mismatch error. When we remove the numbers from the password, the connection succeeds. When we specify just the primary server in the connection string and connect using the password containing numbers, the connection succeeds. When we put the numbers back into password and again specify the 3 nodes in the connection string, the connection fails with a timeout exception and the mongo logs report a key mismatch. We've also tried creating another database with another user using the password random password with the same result. The strange thing is, we have a test environment setup the exact same way and we can't get replicate this issue.



 Comments   
Comment by Chris Robison [ 20/Mar/14 ]

I'm going to try it out today or tomorrow.

Comment by Robert Stam [ 20/Mar/14 ]

We were never able to reproduce this. Did you end up solving the problem?

Comment by Chris Robison [ 01/Jul/13 ]

We verified the password was correct. It still doesn't explain the 30 second timeout exception we are getting.

Comment by Robert Stam [ 01/Jul/13 ]

In my experiment I was able to reproduce the exact same error/log messages by using an invalid password.

That leads me to believe that there may be an invalid password configured somewhere in the client application.

Comment by Chris Robison [ 01/Jul/13 ]

I believe we are still seeing it with one replica set, but others we are not. I don't think there is anything more we can do about it.

Comment by Robert Stam [ 01/Jul/13 ]

Were you able to figure out why you were getting the errors you were getting?

I would like to close this JIRA ticket if you have are no longer having an issue.

Comment by Robert Stam [ 11/Jun/13 ]

I can reproduce the entries in your mongod logs:

Wed May 29 07:38:03.431 [conn10988] authenticate db: prmprod { authenticate: 1, user: "prmprod", nonce: "84e441806a1cd54d", key: "d4b0b743ff1d568d7415aa2f8ca102ca" }
Wed May 29 07:38:03.431 [conn10988] auth: key mismatch prmprod, ns:prmprod

By using an invalid password.

For example, doing this in the MongoDB shell:

c:\mongodb\mongodb-win32-x86_64-2008plus-2.4.3\bin>mongo
MongoDB shell version: 2.4.3
connecting to: test
> db.auth("user", "asdf")
Error: 18 { code: 18, ok: 0.0, errmsg: "auth fails" }
0
>

resulted in these lines in my MongoDB logs:

Tue Jun 11 11:58:35.369 [conn1]  authenticate db: test { authenticate: 1, nonce: "1052984f2a534b1e", user: "user", key: "1449bf7fc76bf88ef8b0c6565ddc3a13"}
Tue Jun 11 11:58:35.370 [conn1] auth: key mismatch user, ns:test

Comment by Chris Robison [ 11/Jun/13 ]

I verified that all keys are the same on all 3 environments for prod. I am also able to login without any issues on each node.

[mongod@wdcmdb1 ~]$ prod1
MongoDB shell version: 2.4.2
connecting to: wdcmdb1:27017/admin
prmp_rs:PRIMARY> exitexit
bye
[mongod@wdcmdb1 ~]$ prod2
MongoDB shell version: 2.4.2
connecting to: wdcmdb2:27017/admin
prmp_rs:SECONDARY> exitexit
bye
[mongod@wdcmdb1 ~]$ prod3
MongoDB shell version: 2.4.2
connecting to: wdcmdb3:27017/admin
prmp_rs:SECONDARY> exitexit
bye

Comment by Robert Stam [ 11/Jun/13 ]

I'm wondering if your replica set members are configured to use authentication but don't have the same keyFile?

Take a look at the Security section on this page:

http://docs.mongodb.org/manual/core/replication/

Do you get an error if you try to connect to the various replica set members from the MongoDB shell?

Comment by Chris Robison [ 30/May/13 ]

Here is a snippet from the mongo logs. This basically gets repeated indefinitely until the timeout occurs.

Wed May 29 07:38:03.431 [conn10988] authenticate db: prmprod

{ authenticate: 1, user: "prmprod", nonce: "84e441806a1cd54d", key: "d4b0b743ff1d568d7415aa2f8ca102ca" }

Wed May 29 07:38:03.431 [conn10988] auth: key mismatch prmprod, ns:prmprod

Comment by Chris Robison [ 30/May/13 ]

Yeah. Sorry it's taking so long. I'm waiting for the systems guys to forward that to me.

Comment by Robert Stam [ 30/May/13 ]

Can you also provide the actual error message you are seeing in the server logs? Thanks.

Comment by Chris Robison [ 30/May/13 ]

Here is the stack trace:

Unable to connect in the specified timeframe of '00:00:30'.
at MongoDB.Driver.Internal.DiscoveringMongoServerProxy.Discover(TimeSpan timeout)
at MongoDB.Driver.Internal.DiscoveringMongoServerProxy.EnsureInstanceManager(TimeSpan timeout)
at MongoDB.Driver.Internal.DiscoveringMongoServerProxy.ChooseServerInstance(ReadPreference readPreference)
at MongoDB.Driver.MongoServer.AcquireConnection(ReadPreference readPreference)
at MongoDB.Driver.MongoCursorEnumerator`1.GetFirst()
at MongoDB.Driver.MongoCursorEnumerator`1.MoveNext()
at MongoDB.Driver.MongoDatabase.GetCollectionNames()
at MongoDB.Driver.MongoDatabase.CollectionExists(String collectionName)
at Elmah.MongoErrorLog.Initialize()
at Elmah.MongoErrorLog..ctor(IDictionary config)

Comment by Robert Stam [ 30/May/13 ]

Not sure what you mean by "key mismatch". Can you provide the actual error message you are seeing in the server logs?

It might also be helpful to provide the actual exception message and stack trace from the C# client program.

Generated at Wed Feb 07 21:37:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.