MySQL Bugs: #91533: Client capability CLIENT_DEPRECATE_EOF incorrectly set in handshake in 5.7

Bug #91533	Client capability CLIENT_DEPRECATE_EOF incorrectly set in handshake in 5.7
Submitted:	2 Jul 2018 23:46	Modified:	10 Jul 2018 13:34
Reporter:	Andy Salnikov (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	Connector / C	Severity:	S3 (Non-critical)
Version:	5.7.21	OS:	Linux (Ubuntu 18.04, CentOS7)
Assigned to:		CPU Architecture:	x86

Description:
We have a mysql-proxy deployed as a middleware agent between mysql clients and mysql server. recently we have switched to mariadb-10.2.14 for backend server and we have discovered that some clients (e.g. JDBC and mysql-5.7) were failing after upgrade unable to run any queries. We believe that this problem is triggered by mysql-proxy not being able to handle new format of text resultset with OK packet instead of EOF packets (see CLIENT_DEPRECATE_EOF capability flag).

To get around that issue we tried to turn off CLIENT_DEPRECATE_EOF flag in server handshake (with a trivial patch in mysql-proxy code). That worked for some clients, e.g. JDBC problem was fixed, but that did not help clients that were based on mysql-5.7. Looking at wireshark dump of the packets we see that mysql-5.7 client always sets CLIENT_DEPRECATE_EOF in client capabilities even if server does not announce that capability. This seems to contradict mysql documentation which states that client should not enable flags not supported by server.

I have also tested few older mysql clients (e.g. 5.5, 5.6) and those never set CLIENT_DEPRECATE_EOF even if server announces it.

How to repeat:
Run mysql-5.7 client against server that does not support CLIENT_DEPRECATE_EOF capability and analyze network packets during handshake.

Suggested fix:
Client have to respect server-provided capabilities and not set any capability flags not supported by server.

Wireshark dump of handshake, port 4040 is mysql-proxy port.

Attachment: Handshake-mysql-5.7.txt (text/plain), 10.71 KiB.

Hello  Andy Salnikov,

Thank you for the bug report.
Could you please provide repeatable test case, server logs (exact steps/sample code,  full Stacktrace etc. - please make it as private if you prefer) to confirm this issue at our end?

Thanks,
Chiranjeevi.

Packet dump with mysqld-5.5 and mysql-client-5.7

Attachment: wireshark-55+57-noproxy.txt (text/plain), 13.33 KiB.

Hi,

to demonstrate the issue I have uploaded a dump of the wireshark packet capture (wireshark-55+57-noproxy.txt) for setup which does not involve mysql-proxy, only mysql server 5.5 and mysql client 5.7. You can see that server handshake announces only a small set of extended capabilities:

        Extended Server Capabilities: 0x800f
            .... .... .... ...1 = Multiple statements: Set
            .... .... .... ..1. = Multiple results: Set
            .... .... .... .1.. = PS Multiple results: Set
            .... .... .... 1... = Plugin Auth: Set
            .... .... ...0 .... = Connect attrs: Not set
            .... .... ..0. .... = Plugin Auth LENENC Client Data: Not set
            .... .... .0.. .... = Client can handle expired passwords: Not set
            .... .... 0... .... = Session variable tracking: Not set
            .... ...0 .... .... = Deprecate EOF: Not set
            1000 000. .... .... = Unused: 0x40

while client handshake packet announce very broad set of capabilities:

        Extended Client Capabilities: 0x01ff
            .... .... .... ...1 = Multiple statements: Set
            .... .... .... ..1. = Multiple results: Set
            .... .... .... .1.. = PS Multiple results: Set
            .... .... .... 1... = Plugin Auth: Set
            .... .... ...1 .... = Connect attrs: Set
            .... .... ..1. .... = Plugin Auth LENENC Client Data: Set
            .... .... .1.. .... = Client can handle expired passwords: Set
            .... .... 1... .... = Session variable tracking: Set
            .... ...1 .... .... = Deprecate EOF: Set
            0000 000. .... .... = Unused: 0x00

My understanding is that this is in a violation of the documented behavior which states that client is supposed to announce only those capabilities which are supported by server (https://dev.mysql.com/doc/internals/en/capability-negotiation.html):

    """The client should only announce the capabilities in the Handshake Response Packet that it has in common with the server."""

This is important to us because tools that depend on protocol internals (e.g. mysql-proxy) need to know which capabilities are negotiated, and if client violates documented behavior it becomes hard to reason about what is actually enabled.

Let me know if you need more info.

Thanks,
Andy

Hello  Andy Salnikov,

Thank you for your feedback.
Verified based on internal discussion with dev's.

Thanks,
Chiranjeevi.