List:General Discussion« Previous MessageNext Message »
From:Michael Stassen Date:March 27 2006 1:40am
Subject:Re: Client does not support authentication protocol requested by server
View as plain text  
Andrew wrote:
>>In the last episode (Mar 26), Andrew said:
>>
>>>What could ever be the problem with the failing Perl DBI (C->B)
>>>connection, if everything is OK with a C->A connection (with and
>>>without Perl), and, in addition, a command-line C->B connection
>>>works?
>>
>>The password on B is a new-style password, and perl on C was built with
>>old mysqlclient libraries?

That is the most likely explanation, I think.

> I'm sorry, this seems to be getting overlooked, each time i attempt to
> convey it:
> 
> For BOTH A and B, the Operating System, the Mysql server and client
> versions & configurations, and (apparently) everything else relevant to
> mysql, IS IDENTICAL! (including firewall, etc.etc.)

No.  They are *supposed* to be identical, but clearly they are not.  I think 
you're asking the wrong question.  You are asking why two identical instances 
would behave differently.  Well, they wouldn't.  I think a better question is, 
what's different?

> Yet, C connects to A, but not to B (within the SAME script and loop)!

Right.  The exact same client works for A, but not for B.  Thus, A and B are 
different.

> If it /is/ a matter of new-style vs. old-style password, PLEASE tell me
> where else to look.  On both A and B, the files /etc/my.cnf are identical
> (with "old_passwords=1" in each).  Where else should I look for a
> difference in configurations?

First, the global configuration file, /etc/my.cnf, can be overridden by a 
server-specific option file and/or command line options.  You can verify what 
the server on B is doing with

   SHOW VARIABLES LIKE 'old_passwords';

One possibility is that this will return "OFF" for server B.  I would *guess* 
that this is not your problem, but it is worth checking.

Second, the difference in authentication is that before 4.1, mysql used a 
16-byte password hash, while 4.1.1 and up use a 41 byte hash.  Hence, the 
password column of the user table is 41 bytes long for both server A and B. 
Now, the old_passwords setting causes mysql to create *new* passwords as 16 byte 
hashes by default, *but it has no effect on pre-existing passwords*.  One likely 
possibility is simply that the user's password was created on A *after* setting 
old_passwords to ON, but was created on B *before* setting old_passwords to ON. 
  That would yield a password hash that is 16 bytes on server A, but 41 bytes on 
server B.  As a result, old-style clients can connect to A, but not to B.  In 
that case, you can fix this by resetting the user's password on server B.

> If C (with MySQL 4.0.25-standard-log) connects to A (5.1.7-beta), as it
> is now (WITHOUT any upgrading), doesn't that indicate that C is capable
> of connecting to B as well (B being identical to A)?  (Something akin to
> transitivity here...)

It would, if A and B were identical.  Hence A and B are not identical.

> completely stumped.
> 
> TIA
> 
> andrew

If neither of my suggestions helps, let us know.  Someone will surely come up 
with another suggestion.

Michael
Thread
Client does not support authentication protocol requested by serverAndrew26 Mar
  • Re: Client does not support authentication protocol requested by serverDan Nelson26 Mar
Re: Client does not support authentication protocol requested byserverAndrew27 Mar
  • Re: Client does not support authentication protocol requested byserverBluejays PC Services27 Mar
  • Re: Client does not support authentication protocol requested by serverMichael Stassen27 Mar