Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.0.4, 5.2.14, 5.3.12, 5.5.33a, 10.0(EOL), 10.1(EOL)
-
Debian 6 x86_64, Connector/J 5.1.20
Description
My application runs on the Resin application server, and uses JDBC Connection pooling. After upgrading
the DB server from Mysql 5.5.29 to MariaDB 5.5.33a it is unable to log in to the database.
The application server is resin 4.0.18, the JDBC connector is Connector/J 5.1.20
I have done some debugging, and the problem seems to be that when the Connection pool hands a connection to the application, it performs a 'change user' command to reset the connection, and MariaDB cannot authenticate this command the way MySQL can.
When the user has no password set, the JDBC pooling + MariaDB connection works.
Specifically, MySQL and MariaDB behaves the same way, until the client issues a 'change user' request.
Replying to this, MySQL sends a response, then the client sends a request type 234, and the change user command is successful.
Replying to this, MariaDB sends a different response, then the client sends a request type 108, and the change user command is unsuccessful.
My test setup:
Client workstation: 10.6.118.61
MariaDB server: 10.6.118.100
Mysql server :10.5.2.36 ( it is behind NAT, it sees the client coming from 193.151.116.11 )
The test cases:
server: MySQL server
client: client workstation
program: Resin pooling + Connector/J
user: 'stoty'/'badpassword'
result: success
server: MariaDB server
client: client workstation
program: Resin pooling + Connector/J
user: 'stoty'/'badpassword'
result: fails
server: MariaDB server
client: MariaDB (resin running locally on DB server)
program: Resin pooling + Connector/J
user: 'root'/ no password
result: success
server: MySQL server
client: client workstation
program: mysql cli
user: 'stoty'/'badpassword'
result: success
server: MariaDB server
client: client workstation
program: mysql cli
user: 'stoty'/'badpassword'
result: success
I have attached the packet capture files for all five test cases.