The Samba-Bugzilla – Attachment 14940 Details for
Bug 13839
CTDB failover does not kill server end of connections for IPv4-mapped IPv6 addresses
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
[patch]
Patch for 4.9
BZ13839-v4-9.patch (text/plain), 5.42 KB, created by
Martin Schwenke
on 2019-03-19 03:51:04 UTC
(
hide
)
Description:
Patch for 4.9
Filename:
MIME Type:
Creator:
Martin Schwenke
Created:
2019-03-19 03:51:04 UTC
Size:
5.42 KB
patch
obsolete
>From c2704c6a980948c26d6a1b14e73dfda39a23d3e9 Mon Sep 17 00:00:00 2001 >From: Zhu Shangzhong <zhu.shangzhong@zte.com.cn> >Date: Tue, 12 Mar 2019 20:49:48 +0800 >Subject: [PATCH 1/2] ctdb: Initialize addr struct to zero before reparsing as > IPV4 > >Failed to kill the tcp connection that using IPv4-mapped IPv6 address >(e.g. ctdb_killtcp eth0 ::ffff:192.168.200.44:2049 >::ffff:192.168.200.45:863). > >When the ctdb_killtcp is used to kill the tcp connection, the IPs and >ports in the connection will be parsed to conn.client and conn.server >(call stack: main->ctdb_sock_addr_from_string->ip_from_string). In >the ip_from_string, as we are using IPv4-mapped IPv6 addresses, the >ipv6_from_string will be used to parse ip to addr.ip6 first. The next >step the ipv4_from_string will be used to reparse ip to addr.ip. > >As a result, the data that dump from conn.server is "2 0 8 1 192 168 >200 44 0 0 0 0 0 0 0 0 0 0 255 255 192 168 200 44 0 0 0 0", the data >from conn.client is "2 0 3 95 192 168 200 45 0 0 0 0 0 0 0 0 0 0 255 255 >192 168 200 45 0 0 0 0". The connection will be add to conn_list by >ctdb_connection_list_add. Then the reset_connections_send uses conn_list >as parameter to start to reset connections in the conn_list. > >In the reset_connections_send, the database "connections" will be >created. The connections from conn_list will be written to the >database(call db_hash_add), and use the data that dump from conn_client >and conn_server as key. > >In the reset_connections_capture_tcp_handler, the >ctdb_sys_read_tcp_packet will receive data on the raw socket. And >extract the IPs and ports from the tcp packet. when extracting IP and >port, the tcp4_extract OR tcp6_extract will be used. Then we got the >new conn.client and conn.server. the data that dump from the >conn.server is "2 0 8 1 192 168 200 44 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 >0 0 0", the data from conn.client is "2 0 3 95 192 168 200 45 0 0 0 0 0 >0 0 0 0 0 0 0 0 0 0 0 0 0 0 0". Finally, we use the data as key to check >if this connection is one being reset(call db_hash_delete). The >db_hash_delete will return ENOENT. Because the two key that being used >by db_hash_delete and db_hash_add are different. > >So, the TCP RST will be NOT sent for the connection forever. We should >initialize addr struct to zero before reparsing as IPV4 in the >ip_from_string. > >BUG: https://bugzilla.samba.org/show_bug.cgi?id=13839 > >Signed-off-by: Zhu Shangzhong <zhu.shangzhong@zte.com.cn> >Reviewed-by: Martin Schwenke <martin@meltin.net> >Reviewed-by: Amitay Isaacs <amitay@samba.org> >(cherry picked from commit 539b5ff32b32b7c75dfaaa119e41f5af6ff1e6fc) >--- > ctdb/protocol/protocol_util.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/ctdb/protocol/protocol_util.c b/ctdb/protocol/protocol_util.c >index a0127a643bc..7edefc6a334 100644 >--- a/ctdb/protocol/protocol_util.c >+++ b/ctdb/protocol/protocol_util.c >@@ -251,6 +251,9 @@ static int ip_from_string(const char *str, ctdb_sock_addr *addr) > if (memcmp(&addr->ip6.sin6_addr.s6_addr[0], > ipv4_mapped_prefix, > sizeof(ipv4_mapped_prefix)) == 0) { >+ /* Initialize addr struct to zero before reparsing as IPV4 */ >+ ZERO_STRUCTP(addr); >+ > /* Reparse as IPv4 */ > ret = ipv4_from_string(p+1, &addr->ip); > } >-- >2.20.1 > > >From e19b78b87a4aa8ab5ffacd7eda3bf4230db6eb84 Mon Sep 17 00:00:00 2001 >From: Martin Schwenke <martin@meltin.net> >Date: Thu, 14 Mar 2019 16:32:02 +1100 >Subject: [PATCH 2/2] ctdb-tests: Add some testing for IPv4-mapped IPv6 address > parsing > >ctdb_sock_addr values are hashed in some contexts. This means that >all of the memory used for the ctdb_sock_addr should be consistent >regardless of how parsing is done. The first 2 cases are just sanity >checks but the 3rd case involving an IPv4-mapped IPv6 address is the >real target of this test addition. > >BUG: https://bugzilla.samba.org/show_bug.cgi?id=13839 > >Signed-off-by: Martin Schwenke <martin@meltin.net> >Reviewed-by: Amitay Isaacs <amitay@samba.org> >(cherry picked from commit d9286701cd9253bf3b42cac3d850ae8c23743e6d) >--- > ctdb/tests/src/protocol_util_test.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > >diff --git a/ctdb/tests/src/protocol_util_test.c b/ctdb/tests/src/protocol_util_test.c >index 5608b13920c..9be95eca2ef 100644 >--- a/ctdb/tests/src/protocol_util_test.c >+++ b/ctdb/tests/src/protocol_util_test.c >@@ -52,6 +52,20 @@ static void test_sock_addr_from_string_bad(const char *ip, bool with_port) > assert(ret == EINVAL); > } > >+static void test_sock_addr_from_string_memcmp(const char *ip1, >+ const char* ip2) >+{ >+ ctdb_sock_addr sa1, sa2; >+ int ret; >+ >+ ret = ctdb_sock_addr_from_string(ip1, &sa1, false); >+ assert(ret == 0); >+ ret = ctdb_sock_addr_from_string(ip2, &sa2, false); >+ assert(ret == 0); >+ ret = memcmp(&sa1, &sa2, sizeof(ctdb_sock_addr)); >+ assert(ret == 0); >+} >+ > static void test_sock_addr_cmp(const char *ip1, const char *ip2, > bool with_port, int res) > { >@@ -299,6 +313,11 @@ int main(int argc, char *argv[]) > test_sock_addr_from_string_bad("junk", false); > test_sock_addr_from_string_bad("0.0.0.0:0 trailing junk", true); > >+ test_sock_addr_from_string_memcmp("127.0.0.1", "127.0.0.1"); >+ test_sock_addr_from_string_memcmp("fe80::6af7:28ff:fefa:d136", >+ "fe80::6af7:28ff:fefa:d136"); >+ test_sock_addr_from_string_memcmp("::ffff:192.0.2.128", "192.0.2.128"); >+ > test_sock_addr_cmp("127.0.0.1", "127.0.0.1" , false, 0); > test_sock_addr_cmp("127.0.0.1", "127.0.0.2" , false, -1); > test_sock_addr_cmp("127.0.0.2", "127.0.0.1" , false, 1); >-- >2.20.1 >
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Flags:
amitay
:
review+
Actions:
View
Attachments on
bug 13839
:
14939
| 14940 |
14941