[MXS-3006] Mysql Workbench fails to connect with "Bad Handshake" Created: 2020-05-25  Updated: 2020-07-03  Resolved: 2020-07-03

Status: Closed
Project: MariaDB MaxScale
Component/s: N/A
Affects Version/s: 2.4.9
Fix Version/s: N/A

Type: Bug Priority: Minor
Reporter: Robert Buchinger Assignee: markus makela
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

CentOS 7.8.2003
MaxScale 2.4.9 - 321126660f222a96c2f5132de50f496199644483
CMake flags: -DBUILD_TESTS=N -DBUILD_MMMON=Y -DBUILD_CDC=Y -DPACKAGE=Y -DDISTRIB_SUFFIX=centos.7
Jenkins build: jenkins-build-185


 Description   

When trying to connect to the proxy it seems that at least MysqlWorkbench fails with a bad handshake error (have tested DBeaver, Navicat, ... they all work fine)

According to Wireshark: (password string masked with XXX)

R...
5.5.5-10.2.23-MariaDB-log ..... ).;OQ.h...!...............DV0.^9&=:a)g.mysql_native_password.>..........@........................robert..caching_sha2_password.,....mysql_native_password. XXXXXXXXXXXXXXXXXXX............#08S01Bad handshake

Could this be related to MXS-2525 ?

 Comments   
Comment by markus makela [ 2020-07-03 ]

Tested with MaxScale 2.4.10 and MariaDB 10.3 with MySQL Workbench 8.0.20 on Fedora 30 and it seems to work. Adding versiong_string=5.7.10-mysql to the MaxScale service seems to reproduce the issue, looks like the problem is in MySQL workbench as it doesn't seem to understand a AuthSwitchRequest packet:

Show all

 
T 127.0.0.1:4006 -> 127.0.0.1:48152 [AP] #4
 
  50 00 00 00 0a 35 2e 37    2e 31 30 2d 6d 79 73 71    P....5.7.10-mysq
 
  6c 00 06 00 00 00 4c 64    6a 26 4a 2e 41 43 00 de    l.....Ldj&J.AC..
 
  f7 08 02 00 0f 00 15 00    00 00 00 00 00 04 00 00    ................
 
  00 23 67 37 2d 29 32 68    34 27 6a 3c 35 00 6d 79    .#g7-)2h4'j<5.my
 
  73 71 6c 5f 6e 61 74 69    76 65 5f 70 61 73 73 77    sql_native_passw
 
  6f 72 64 00                                           ord.            
##
 
T 127.0.0.1:48152 -> 127.0.0.1:4006 [AP] #6
 
  3f 00 00 01 05 a6 ff 01    00 00 00 40 ff 00 00 00    ?..........@....
 
  00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
 
  00 00 00 00 6d 61 78 75    73 65 72 00 00 63 61 63    ....maxuser..cac
 
  68 69 6e 67 5f 73 68 61    32 5f 70 61 73 73 77 6f    hing_sha2_passwo
 
  72 64 00                                              rd.             
##
 
T 127.0.0.1:4006 -> 127.0.0.1:48152 [AP] #8
 
  2c 00 00 02 fe 6d 79 73    71 6c 5f 6e 61 74 69 76    ,....mysql_nativ
 
  65 5f 70 61 73 73 77 6f    72 64 00 4c 64 6a 26 4a    e_password.Ldj&J
 
  2e 41 43 23 67 37 2d 29    32 68 34 27 6a 3c 35 00    .AC#g7-)2h4'j<5.
 
##
 
T 127.0.0.1:48152 -> 127.0.0.1:4006 [AP] #10
 
  00 00 00 03                                           ....            
##
 
T 127.0.0.1:4006 -> 127.0.0.1:48152 [AP] #12
 
  16 00 00 04 ff 15 04 23    30 38 53 30 31 42 61 64    .......#08S01Bad
 
  20 68 61 6e 64 73 68 61    6b 65                       handshake

I think I managed to fix this by recreating the database connection in Workbench and adding the credentials to the cache. This seems to have refreshed the server version information which it appears to ignore upon reconnection.

Comment by markus makela [ 2020-07-03 ]

Closing as Not a Bug as it's a problem in MySQL Workbench.

Generated at Thu Feb 08 04:18:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.