If the server returns a packet with an error number in the range between 2000 and 2999, the client library reports it as a malformed packet. This is technically a breaking change as it's not documented anywhere in the protocol or in the error code listings that the range 2000 to 2999 is reserved for client errors and they must be treated as malformed packets.

This breaks a module in MaxScale that (mistakenly) used the error code 2003 for an error it generated. If this range of error numbers is reserved for clients, it should be documented.

The commit that causes this is 4419abe71aef1d0b6ca0fab8fc67f02845b1e081. While this is merely a client-side change, it should either be reverted to retain the old documented behavior or it should be documented that the range 2000 to 2999 is reserved for client-side errors and any error packet from that range must be considered a malformed packet. I'd prefer the latter as it requires no changes to the server and/or client code and merely a fix in MaxScale.

Here is a post-authentication network capture that in 10.6 is reported as a "normal" error but in 10.11 is reported as a malformed packet:

T 192.168.122.1:36730 -> 192.168.122.131:4006 [AP] #105

  1f 00 00 00 03 49 4e 53    45 52 54 20 49 4e 54 4f    .....INSERT INTO

  20 74 65 73 74 2e 74 32    20 56 41 4c 55 45 53 20     test.t2 VALUES 

  28 31 29                                              (1)             

#

T 192.168.122.131:4006 -> 192.168.122.1:36730 [AP] #106

  1e 00 00 01 ff d3 07 23    48 59 30 30 30 49 6e 76    .......#HY000Inv

  61 6c 69 64 20 69 6e 73    65 72 74 20 74 61 72 67    alid insert targ

  65 74                                                 et              

#

If nothing else, the error message is misleading since the packet itself is well-formed and it's only the error that is unknown.