Address family of server side mismatches with that of client side

[geliangtang]

diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh
index fafd19ec7e1f..0fd1e2f75bde 100755
--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
+++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh
@@ -1833,12 +1833,17 @@ subflows_tests()
        fi
 
        # subflow
-       if reset "single subflow"; then
+       if reset_with_events "single subflow"; then
                pm_nl_set_limits $ns1 0 1
                pm_nl_set_limits $ns2 0 1
                pm_nl_add_endpoint $ns2 10.0.3.2 flags subflow
                run_tests $ns1 $ns2 10.0.1.1
                chk_join_nr 1 1 1
+               echo "ns1:"
+               cat $evts_ns1
+               echo "ns2:"
+               cat $evts_ns2
+               kill_events_pids
        fi
 
        # multiple subflows

> sudo ./mptcp_join.sh -f

Created /tmp/tmp.DmRiCONIkN (size 1 KB) containing data sent by client
Created /tmp/tmp.NNizKh9RtU (size 1 KB) containing data sent by server
001 no JOIN                              syn[ ok ] - synack[ ok ] - ack[ ok ]
002 single subflow, limited by client    syn[ ok ] - synack[ ok ] - ack[ ok ]
003 single subflow, limited by server    syn[ ok ] - synack[ ok ] - ack[ ok ]
004 single subflow                       syn[ ok ] - synack[ ok ] - ack[ ok ]
ns1:
type:15,family:10,sport:10003,saddr6:::
type:1,token:3827302342,server_side:1,family:10,saddr6:::ffff:10.0.1.1,daddr6:::ffff:10.0.1.2,sport:10003,dport:43490,loc_id:0,rem_id:0
type:2,token:3827302342,server_side:1,family:10,saddr6:::ffff:10.0.1.1,daddr6:::ffff:10.0.1.2,sport:10003,dport:43490,loc_id:0,rem_id:0
type:10,token:3827302342,family:10,saddr6:::ffff:10.0.1.1,daddr6:::ffff:10.0.3.2,sport:10003,dport:53253,loc_id:0,rem_id:1,backup:0
type:3,token:3827302342
type:16,family:10,sport:10003,saddr6:::
ns2:
type:1,token:119841803,server_side:0,family:2,saddr4:10.0.1.2,daddr4:10.0.1.1,sport:43490,dport:10003,loc_id:0,rem_id:0
type:2,token:119841803,server_side:0,family:2,saddr4:10.0.1.2,daddr4:10.0.1.1,sport:43490,dport:10003,loc_id:0,rem_id:0
type:10,token:119841803,family:2,saddr4:10.0.3.2,daddr4:10.0.1.1,sport:53253,dport:10003,loc_id:1,rem_id:0,backup:0
type:3,token:119841803
005 multiple subflows                    syn[ ok ] - synack[ ok ] - ack[ ok ]
006 multiple subflows, limited by server syn[ ok ] - synack[ ok ] - ack[ ok ]
007 single subflow, dev                  syn[ ok ] - synack[ ok ] - ack[ ok ]

[matttbe]

Hi Geliang,

It doesn't look like an issue to me, it is just that on the server side (ns1), the family is set to AF_INET6 and the v4 address is mapped in a v6 one.

But the rest seems OK, no?

• first subflow: 10.0.1.2 → 10.0.1.1
• second one: 10.0.3.2 → 10.0.1.1

[geliangtang]

Yes, the rest is OK. It's better to set the family to AF_INET4 here.

Could you tell me which lines of code set the family to AF_INET6? I didn't find it yet.

[matttbe]

If I'm not mistaken, the server always create a listen socket in AF_INET6 to be able to accept subflows in v4 and v6.

Why is it an issue for you? If you need to parse stuff, can you not simply remove ::ffff:? e.g. directly in bash:

ip="::ffff:10.0.1.1"
echo ${ip#::ffff:}

[matttbe]

Hi @geliangtang,

Are you still affected by this issue? It is not clear to me if it is really an issue or something else (v4 mapped in v6) to take into account.

[matttbe]

I guess this question was related to this patch (we can see: addr="::ffff:$addr"): https://patchwork.kernel.org/project/mptcp/patch/3ddbc897e2e5a766a2b4df591e747126288661ff.1681463340.git.geliang.tang@suse.com/

I guess we can close this ticket then. Feel free to re-open it if needed.