| Bug #34381 | Client applications cannot connect to server on Vista | ||
|---|---|---|---|
| Submitted: | 7 Feb 15:33 | Modified: | 3 Mar 21:21 |
| Reporter: | Chuck Bell | ||
| Status: | Closed | ||
| Category: | Client | Severity: | S1 (Critical) |
| Version: | 6.0.5 | OS: | Microsoft Windows (Vista Business) |
| Assigned to: | Vladislav Vaintroub | Target Version: | 6.0-rc |
| Triage: | D1 (Critical) | ||
[7 Feb 19:22]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/41881 ChangeSet@1.2536, 2008-02-07 19:19:32+01:00, vvaintroub@wva. +2 -0 BUG#34381- Client application cannot connect to server on Vista. The problem was that the server is creating an IPv6 socket and listens to IPv6-only traffic. If an older client application tries to connect server using IPv4 address (like 127.0.0.1 for local host), it fails. The solution is to clear IPV6_V6ONLY socket option before bind() - in this case we'll have dual-mode socket that accepts both IPv4 and IPv6 traffic.
[7 Feb 19:58]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/41887 ChangeSet@1.2536, 2008-02-07 19:58:16+01:00, vvaintroub@wva. +2 -0 BUG#34381- Client application cannot connect to server on Vista. The problem was that the server is creating an IPv6 socket and listens to IPv6-only traffic. If an older client application tries to connect server using IPv4 address (like 127.0.0.1 for local host), it fails. The solution is to clear IPV6_V6ONLY socket option before bind() - in this case we'll have dual-mode socket that accepts both IPv4 and IPv6 traffic.
[8 Feb 20:48]
Chuck Bell
Patch approved.
[12 Feb 13:48]
Vladislav Vaintroub
Patch approved by Magnus via email The latest commit is http://lists.mysql.com/commits/42103
[25 Feb 21:19]
Bugs System
Pushed into 6.0.5-alpha
[3 Mar 19:19]
Bugs System
Pushed into 6.0.5-alpha
[3 Mar 21:21]
Paul DuBois
Noted in 6.0.5 changelog. Client applications could not connect to the server on Windows Vista because the server was creating an IPv6-only TCP/IP socket.
Description: The mysql client applications cannot connect to the server in the latest mysql-6.0 clone. As a result, the test suite does not connect and eventually timesout. Cannot run tests on Vista. The server starts but the clients fail to connect with messages similar to: D:\source\c++\mysql-6.0_BUG_34298\client\debug>mysqladmin -uroot shutdown mysqladmin: connect to server at 'localhost' failed error: 'Can't connect to MySQL server on 'localhost' (10061)' Check that mysqld is running on localhost and that the port is 3306. You can check this by doing 'telnet localhost 3306' The output of netstat shows that mysqld is listening on the IPv6 wildcard address: TCP [::]:9306 [::]:0 LISTENING 940 ...which indicates the server is communicating using IPv6 only while the dump of the client applications who they are communicating using IPv4. These problems seem to be isolated to Vista as it does not appear on XP. How to repeat: clone mysql-6.0 build on Windows Vista run ./mysql-test-run.pl Suggested fix: Patch the server to communicate on both IPv6 and IPv4. Sample patch: ===== sql/mysqld.cc 1.647 vs edited ===== --- 1.647/sql/mysqld.cc 2008-01-29 02:50:45 -05:00 +++ edited/sql/mysqld.cc 2008-02-07 08:38:57 -05:00 @@ -1657,7 +1657,19 @@ user to open two mysqld servers with the same TCP/IP port. */ (void) setsockopt(ip_sock,SOL_SOCKET,SO_REUSEADDR,(char*)&arg,sizeof(arg)); -#endif /* __WIN__ */ +#else /* __WIN__ */ +#ifndef IPV6_V6ONLY +#define IPV6_V6ONLY 27 +#endif + /* + For interoperability with older clients, listen on both IPv6 and IPv4 + wildcard addresses + */ + arg = 0; + if (ai->ai_family == AF_INET6) + (void) setsockopt(ip_sock,IPPROTO_IPV6,IPV6_V6ONLY,(char*)&arg,sizeof(a rg)); + +#endif /* Sometimes the port is not released fast enough when stopping and restarting the server. This happens quite often with the test suite