The following tests failed:

	  5 - odbc_info (Failed)

	  7 - odbc_catalog1 (Failed)

	  8 - odbc_catalog2 (Failed)

	 20 - odbc_error (Failed)

	 21 - odbc_param (Failed)

Probably won't hurt to mention, that atm C/ODBC requires use_sql_variables_in=master to make some of catalog functions work

I don't know what MaxScale version uses Connectors SkySQL insctance, but in the Travis atm there is
1) a number of failures about stmt id -1([HY000] (1243) [ma-3.1.17][10.6.4-1-MariaDB-enterprise-log]Unknown prepared statement handler (4294967295) for COM_STMT_EXECUTE given to MaxScale). C/ODBC uses direct execution(aka stmt id -1) a lot.
2) There is one failure with the same error for "normal" stmt id ([HY000] (1243) [ma-3.1.17][10.6.4-1-MariaDB-enterprise-log]Unknown prepared statement handler (24) for COM_STMT_EXECUTE given to MaxScale)
3) There is one failure not detecting of the dead connection, that has been killed from other connection with KILL. According to Markus the correct KILL routing is something that MaxScale is supposed to care about. There is seemingly 3 such testcases. In 2nd KILL command succeeds, and the "killed" connection is still live.
4) One test setting interactive timeout is failing - the wait_timeout value is not equal to the expected value(of the interactive_timeout)

And that's it atm, but few tests are currently falling because of testing environment misconfiguration, they may also disguise some real problems

The t_bug14639 test uses a prepared statement with SELECT connection_id() to extract the connection ID. As MaxScale won't intercept it, it'll get routed to a backend and it'll return the wrong connection ID. Instead, the connector could use the value of mysql_thread_id() from the C connector to get the session ID.

t_bug26934 also suffers from the same problem.

Adding users_refresh_time=0s under the [maxscale] section makes odbc_catalog2 pass. This happens because the test repeatedly creates new databases and then attempts to log into them. As MaxScale by default throttles the fetching of the database information, the authentication will fail.

t_bug3456_fails_due_to_conc_bug and t_bug59772 also fail as the tests use prepared statements to get the connection ID.

An additional reason why the test fails is that even if the KILL handling in MaxScale is bypassed by enclosing the command inside of an executable comment, the error that MaxScale writes into the socket causes the COM_PING that it uses to check if the connection is alive to receive a response when none is expected. Using SO_LINGER to forcibly close the socket works but a better alternative might be to not write an error if the client is idle and not expecting a response.

I'll close this as most of these are known limitations or can be avoided by changing the configuration.