Subflow creation fails?

[SriramScorp]

Have 4 USB modems (usb0, usb1, usb2, usb3) for WAN, one ethernet as LAN (eth0). cat /proc/net/mptcp_net/mptcp shows multiple entries with single subflow (ns) instead of single entry with multiple subflows. Traffic only flows through the interface with lowest metric.

root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # uname -r
5.4.83-MPTCP+
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # sysctl -a 2>/dev/null | grep -iE 'mptcp|congest'
fs.nfs.nfs_congestion_kb = 28992
kernel.osrelease = 5.4.83-MPTCP+
net.ipv4.tcp_allowed_congestion_control = reno cubic
net.ipv4.tcp_available_congestion_control = reno cubic mctcpdesync
net.ipv4.tcp_congestion_control = cubic
net.mptcp.mptcp_checksum = 0
net.mptcp.mptcp_debug = 0
net.mptcp.mptcp_enabled = 1
net.mptcp.mptcp_path_manager = fullmesh
net.mptcp.mptcp_scheduler = default
net.mptcp.mptcp_syn_retries = 3
net.mptcp.mptcp_version = 0
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # for i in 0 1 2 3 ; do echo && ip rule list table usb$i ; done

32761:  from 192.168.42.131 lookup usb0
32762:  from all fwmark 0x1e lookup usb0

32759:  from 192.168.42.172 lookup usb1
32760:  from all fwmark 0xa lookup usb1

32757:  from 192.168.42.183 lookup usb2
32758:  from all fwmark 0x14 lookup usb2

32763:  from 192.168.42.191 lookup usb3
32764:  from all fwmark 0x28 lookup usb3
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # for i in 0 1 2 3 ; do echo && ip route list table usb$i ; done

default via 192.168.42.1 dev usb0 
192.168.1.0/24 dev eth0 scope link 
192.168.42.0/24 dev usb0 scope link 

default via 192.168.42.1 dev usb1 
192.168.1.0/24 dev eth0 scope link 
192.168.42.0/24 dev usb1 scope link 

default via 192.168.42.1 dev usb2 
192.168.1.0/24 dev eth0 scope link 
192.168.42.0/24 dev usb2 scope link 

default via 192.168.42.1 dev usb3 
192.168.1.0/24 dev eth0 scope link 
192.168.42.0/24 dev usb3 scope link 
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /proc/net/mptcp_fullmesh 
Index, Address-ID, Backup, IP-address, if-idx
IPv4, next v4-index: 7
1, 2, 0, 192.168.42.191, 6
2, 3, 0, 192.168.42.131, 3
3, 4, 0, 192.168.42.172, 4
4, 5, 0, 192.168.42.183, 5
IPv6, next v6-index: 0
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /sys/module/mptcp_fullmesh/parameters/num_subflows 
1
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /proc/net/mptcp_net/mptcp
  sl  loc_tok  rem_tok  v6 local_address                         remote_address                        st ns tx_queue rx_queue inode
   0: FFFFFFFF FFFFFFFF  0 1001A8C0:8842                         1001A8C0:0FA0                         01 01 00000000:00000000 35381
   1: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8842                         01 01 00000000:00000000 35852
   2: FFFFFFFF FFFFFFFF  0 1001A8C0:8834                         1001A8C0:0FA0                         01 01 00000000:00000000 36865
   3: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8826                         01 01 00000000:00000000 34379
   4: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8834                         01 01 00000000:00000000 34397
   5: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:882C                         01 01 00000000:00000000 34391
   6: FFFFFFFF FFFFFFFF  0 1001A8C0:8826                         1001A8C0:0FA0                         01 01 00000000:00000000 33786
   7: FFFFFFFF FFFFFFFF  0 1001A8C0:AD9F                         0301A8C0:D222                         01 01 00000000:00000000 74714
   8: FFFFFFFF FFFFFFFF  0 1001A8C0:882C                         1001A8C0:0FA0                         01 01 00000000:00000000 31742
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # 

[matttbe]

Hi @SriramScorp

Why do you have this route in each table?

192.168.1.0/24 dev eth0 scope link 

Because it looks like you create connections to this prefix, right? So everything go through eth0, no?

If you have issue to create other subflows on other devices, it is also good to look at logs in dmesg after having enabled sysctl -w net.mptcp.mptcp_debug=1. Some IPTables or SELinux rules can block the creation of new subflows.

[SriramScorp]

That route entry is for the LAN subnet (192.168.1.0/24) and was adapted from here. The setup falls back to iptables-based load balancing when aggregation with shadowsocks fails.

[matttbe]

Do you have the same issue if your remove this route in all usbX tables?

[SriramScorp]

Yes, the issue still persists.

Meanwhile, I turned off mptcp for all but one of the USB modems. The cat /proc/net/mptcp_net/mptcp output still has 8 entries and is persistently the same. Morever, the same output is displayed even when shadowsocks is stopped and there are no known connections to the internet. Something has went awry. It was working until a week back.

root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /proc/net/mptcp_fullmesh 
Index, Address-ID, Backup, IP-address, if-idx
IPv4, next v4-index: 8
3, 4, 0, 192.168.42.172, 4
IPv6, next v6-index: 0
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /proc/net/mptcp_net/mptcp 
  sl  loc_tok  rem_tok  v6 local_address                         remote_address                        st ns tx_queue rx_queue inode
   0: FFFFFFFF FFFFFFFF  0 1001A8C0:8842                         1001A8C0:0FA0                         01 01 00000000:00000000 35381
   1: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8842                         01 01 00000000:00000000 35852
   2: FFFFFFFF FFFFFFFF  0 1001A8C0:8834                         1001A8C0:0FA0                         01 01 00000000:00000000 36865
   3: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8826                         01 01 00000000:00000000 34379
   4: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:8834                         01 01 00000000:00000000 34397
   5: FFFFFFFF FFFFFFFF  0 1001A8C0:0FA0                         1001A8C0:882C                         01 01 00000000:00000000 34391
   6: FFFFFFFF FFFFFFFF  0 1001A8C0:AD9F                         1901A8C0:808A                         01 01 00000000:00000000 1576781
   7: FFFFFFFF FFFFFFFF  0 1001A8C0:8826                         1001A8C0:0FA0                         01 01 00000000:00000000 33786
   8: FFFFFFFF FFFFFFFF  0 1001A8C0:882C                         1001A8C0:0FA0                         01 01 00000000:00000000 31742
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # 

[matttbe]

All connections from the list are between the same prefix (01A8C0 → 192.168.1).

All connections except one are between the same addresses (1001A8C0 → 192.168.1.16): then it is probably normal you don't use MPTCP there. Not sure about the remaining one (192.168.1.25)

[SriramScorp]

'192.168.1.16' is the IP of the mptcp based router. '192.168.1.25' is one of the systems in the LAN network from where I ssh into the router. MPTCP has been turned off on the LAN interface 'eth0'. So, does that mean the cat output corresponds to the SSH connection b/w the two systems?

I have a similar setup in another device where I don't see the LAN traffic showing up in the cat output.

[matttbe]

All "local" connections (from 192.168.1.16 to 192.168.1.16) are from/to the port 4000. I'm not sure what it is but mainly I'm not sure why you have MPTCP connection entries for "localhost" connections but certainly that's why you don't use your USB modems.

Same for the SSH connection: I guess you cannot use them for LAN connections.

Did I miss something else?

[SriramScorp]

I don't know what is happening either. The exact same setup was working until a week back. How do I decode the IP-Port combinations from the 'local_address' & 'remote_address' columns?

[matttbe]

I don't know what is happening either. The exact same setup was working until a week back.

It looks like the issue is somewhere else: your app is not creating MPTCP connections (or from an ip netns?) Feel free to close the issue if it is not directly linked to MPTCP.

How do I decode the IP-Port combinations from the 'local_address' & 'remote_address' columns?

It is in hexa and reversed, e.g. for 1001A8C0:

• 10 → 16
• 01 → 1
• A8 → 168
• C0 → 192

→ 192.168.1.16.

(I'm sure there are online web service to convert them automatically if needed)

[SriramScorp]

It is in hexa and reversed, e.g. for 1001A8C0:

Well, this is cool.

While the fact that traffic bound to the internet not utilitzing all mptcp-enabled interfaces is infact the real issue, I still don't understand why traffic to/from the LAN network and within the router itself are making it to the cat output!! Is that supposed to happen?

[matttbe]

While the fact that traffic bound to the internet not utilitzing all mptcp-enabled interfaces is infact the real issue, I still don't understand why traffic to/from the LAN network and within the router itself are making it to the cat output!! Is that supposed to happen?

From what I see, there is no outbound traffic at all. At least in the main NS. Did you check if you have different network namespaces? ip netns Or do you use containers (docker, lxd, nspawn) or VMs?

localhost traffic should not use MPTCP.

[SriramScorp]

From what I see, there is no outbound traffic at all.

There is outbound traffic but it is not showing up in the cat output. I have an instance of shadowsocks client running and connected to a VPS. I have configured the router (192.168.1.16) as the default gateway for the one of the systems in the LAN network (192.168.1.25). The system is able to access the internet via the router and with the public IP of the ss-server. I have also configured reverse port-forwarding via SSH tunnel from the router to the ss-server to enable direct access to the router through the shadowsocks server. None of these connections are listed in cat /proc/net/mptcp_net/mptcp or netstat -m.

Did you check if you have different network namespaces?

Yes. There are no network namespaces.

root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # ip netns
root@raspi-mptcp:~ # 

Or do you use containers (docker, lxd, nspawn) or VMs?

This is a RaspberryPi-3 running 32-bit raspbian OS with no containerization or virtualization.

root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /proc/device-tree/model 
Raspberry Pi 3 Model B Plus Rev 1.3
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # uname -m
armv7l
root@raspi-mptcp:~ # 

Enabling debugging sysctl -w net.mptcp.mptcp_debug=1 didn't produce any extra logs in dmesg either.

[matttbe]

There is outbound traffic but it is not showing up in the cat output

Can you see some connections with netstat -t or cat /proc/net/tcp*?

• If yes, maybe it cannot establish MPTCP connections with the server? (firewall/middlebox/server config/...): take packet traces to understand what's going on.
• If no, you need to check in which environment the proxy is running

[SriramScorp]

Can you see some connections with netstat -t or cat /proc/net/tcp*?

Yes, I can see the incoming ssh connection to the router and the outgoing ssh-tunnel to the server in netstat -t. So, I found that the ISP was blocking plain shadowsocks.

root@raspi-mptcp:~ # 
root@raspi-mptcp:~ # curl http://multipath-tcp.org
Nay, Nay, Nay, your have an old computer that does not speak MPTCP. Shame on you!
root@raspi-mptcp:~ #

After enabling v2ray plugin, the connection was detected as MPTCP. Still, no outbound connections visible in netstat -m.

root@raspi-mptcp:~ #  
root@raspi-mptcp:~ # curl http://multipath-tcp.org
Yay, you are MPTCP-capable! You can now rest in peace.
root@raspi-mptcp:~ # 

However, post enabling v2ray, I have the following stacktrace in my dmesg.

[13860.054300] ------------[ cut here ]------------
[13860.054343] WARNING: CPU: 3 PID: 0 at lib/percpu-refcount.c:160 percpu_ref_switch_to_atomic_rcu+0x194/0x198
[13860.054361] percpu ref (cgroup_bpf_release_fn) <= 0 (-17) after switching to atomic
[13860.054367] Modules linked in: xt_connmark xt_addrtype xt_TPROXY nf_tproxy_ipv6 nf_tproxy_ipv4 xt_mark tun joydev binfmt_misc rfcomm cmac bn
ep hci_uart btbcm bluetooth ecdh_generic ecc xt_CHECKSUM 8021q garp stp llc nf_tables nfnetlink xt_limit ipt_REJECT nf_reject_ipv4 xt_state xt_
conntrack xt_tcpudp iptable_filter xt_MASQUERADE iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle sg brcmfmac brcmu
til rndis_host cdc_ether cfg80211 rfkill raspberrypi_hwmon bcm2835_isp(C) bcm2835_v4l2(C) bcm2835_codec(C) snd_bcm2835(C) v4l2_mem2mem bcm2835_
mmal_vchiq(C) videobuf2_dma_contig videobuf2_vmalloc snd_pcm videobuf2_memops videobuf2_v4l2 videobuf2_common snd_timer snd videodev mc vc_sm_c
ma(C) uio_pdrv_genirq uio pppoe pppox ppp_generic slhc i2c_dev ip_tables x_tables sha256_generic essiv authenc aes_arm_bs crypto_simd cryptd al
gif_skcipher af_alg sr_mod cdrom dm_crypt dm_mod i2c_bcm2835
[13860.054752] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G         C        5.4.83-MPTCP+ #1
[13860.054757] Hardware name: BCM2835
[13860.054762] Backtrace: 
[13860.054782] [<c020e1c8>] (dump_backtrace) from [<c020e544>] (show_stack+0x20/0x24)
[13860.054795]  r7:ffffffff r6:00000000 r5:60000113 r4:c12a1910
[13860.054813] [<c020e524>] (show_stack) from [<c0af1890>] (dump_stack+0xd4/0x118)
[13860.054832] [<c0af17bc>] (dump_stack) from [<c02224fc>] (__warn+0xe0/0x108)
[13860.054846]  r10:ffffe000 r9:c1204ff8 r8:00000009 r7:000000a0 r6:c06b58d8 r5:00000009
[13860.054853]  r4:c0e12b24 r3:00000000
[13860.054867] [<c022241c>] (__warn) from [<c02228fc>] (warn_slowpath_fmt+0xa8/0xd0)
[13860.054878]  r7:c06b58d8 r6:000000a0 r5:c0e12b24 r4:c0e12b3c
[13860.054895] [<c0222858>] (warn_slowpath_fmt) from [<c06b58d8>] (percpu_ref_switch_to_atomic_rcu+0x194/0x198)
[13860.054907]  r8:c12056ec r7:c12050cc r6:ce7e0b94 r5:ce7e0ba8 r4:7fffffee
[13860.054926] [<c06b5744>] (percpu_ref_switch_to_atomic_rcu) from [<c0296b98>] (rcu_core+0x3b0/0x658)
[13860.054941]  r9:ef55cf2c r8:e9d23e24 r7:c1211400 r6:c1204ff0 r5:00000000 r4:0000000a
[13860.054957] [<c02967e8>] (rcu_core) from [<c0296e58>] (rcu_core_si+0x18/0x1c)
[13860.054971]  r10:e9d22000 r9:00000002 r8:e9c67000 r7:00000100 r6:00000009 r5:00000002
[13860.054976]  r4:c12030a4
[13860.054993] [<c0296e40>] (rcu_core_si) from [<c0202480>] (__do_softirq+0x190/0x414)
[13860.055011] [<c02022f0>] (__do_softirq) from [<c0228830>] (irq_exit+0xdc/0x100)
[13860.055024]  r10:00000000 r9:e9d22000 r8:e9c67000 r7:00000000 r6:00000001 r5:00000000
[13860.055030]  r4:ffffe000
[13860.055046] [<c0228754>] (irq_exit) from [<c0283b8c>] (__handle_domain_irq+0x70/0xc0)
[13860.055054]  r5:00000000 r4:c10ae2a4
[13860.055069] [<c0283b1c>] (__handle_domain_irq) from [<c0202224>] (bcm2836_arm_irqchip_handle_irq+0x64/0xa4)
[13860.055082]  r9:e9d22000 r8:c12a837b r7:e9d23f6c r6:ffffffff r5:60000013 r4:c0209c10
[13860.055095] [<c02021c0>] (bcm2836_arm_irqchip_handle_irq) from [<c0201a3c>] (__irq_svc+0x5c/0x7c)
[13860.055103] Exception stack(0xe9d23f38 to 0xe9d23f80)
[13860.055112] 3f20:                                                       c0209c0c 00000000
[13860.055125] 3f40: 60000093 60000093 e9d22000 00000003 c1204ff0 c1205038 c12a837b c0dd2cc4
[13860.055137] 3f60: 00000000 e9d23f94 ffffe000 e9d23f88 e9d22000 c0209c10 60000013 ffffffff
[13860.055158] [<c0209bdc>] (arch_cpu_idle) from [<c0b10884>] (default_idle_call+0x34/0x48)
[13860.055175] [<c0b10850>] (default_idle_call) from [<c0257e34>] (do_idle+0xec/0x16c)
[13860.055188] [<c0257d48>] (do_idle) from [<c025819c>] (cpu_startup_entry+0x28/0x2c)
[13860.055201]  r9:410fd034 r8:00007000 r7:c12bb360 r6:30c0387d r5:00000003 r4:0000008a
[13860.055217] [<c0258174>] (cpu_startup_entry) from [<c0210d48>] (secondary_start_kernel+0x168/0x174)
[13860.055232] [<c0210be0>] (secondary_start_kernel) from [<002027ac>] (0x2027ac)
[13860.055239]  r5:00000000 r4:29cc1a40
[13860.055248] ---[ end trace 7dcf0ff461a586eb ]---

Meanwhile, sysctl -w net.mptcp.mptcp_debug=1 created the following in dmesg, each set of logs created after running curl ipinfo.io from the LAN system (192.168.1.25) once.

[14318.141878] mptcp_alloc_mpcb: created mpcb with token 0x48313e03
[14318.141911] mptcp_add_sock: token 0x48313e03 pi 1, src_addr:34.117.59.81:80 dst_addr:192.168.1.25:34264
[14318.573628] mptcp_close: Close of meta_sk with tok 0x48313e03
[14318.574474] mptcp_del_sock: Removing subsock tok 0x48313e03 pi:1 state 7 is_meta? 0
[14318.574504] mptcp_sock_destruct destroying meta-sk token 0x48313e03

[15019.098284] mptcp_alloc_mpcb: created mpcb with token 0x3aebd847
[15019.098345] mptcp_add_sock: token 0x3aebd847 pi 1, src_addr:34.117.59.81:80 dst_addr:192.168.1.25:39350
[15020.119937] mptcp_close: Close of meta_sk with tok 0x3aebd847
[15020.120890] mptcp_del_sock: Removing subsock tok 0x3aebd847 pi:1 state 7 is_meta? 0
[15020.120924] mptcp_sock_destruct destroying meta-sk token 0x3aebd847

[matttbe]

So, I found that the ISP was blocking plain shadowsocks.

Best to report the issue to your ISP. Most of the time, it was not their intension to block MPTCP. Tell them it is used by millions of devices in the world (mainly from Apple products).

Feel free to mention here the country and the ISP to help other users (and a ticket ID if you have one with the operator).

Do you mind if I close the ticket as there is anything I can do?

However, post enabling v2ray, I have the following stacktrace in my dmesg.

I don't see a direct link with MPTCP (no mention of mptcp in the call trace). Probably something else. If you find a link, please open a new bug report.

[SriramScorp]

Debug logs are created in dmesg. But only one subflow in all?

@matttbe I think this issue is still related to failure in subflow creation. I have the below logs from another working device (socks server IP and Port obfuscated as 4.3.2.1 and 8388 respectively).

[226089.716016] mptcp_alloc_mpcb: created mpcb with token 0xd696d176
[226089.716075] mptcp_add_sock: token 0xd696d176 pi 1, src_addr:192.168.42.162:58440 dst_addr:4.3.2.1:8388
[226089.803909] mptcp_add_sock: token 0xd696d176 pi 2, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.803954] __mptcp_init4_subsockets: token 0xd696d176 pi 2 src_addr:192.168.42.81:0 dst_addr:4.3.2.1:8388 ifidx: 151
[226089.804202] mptcp_add_sock: token 0xd696d176 pi 3, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.804234] __mptcp_init4_subsockets: token 0xd696d176 pi 3 src_addr:192.168.42.167:0 dst_addr:4.3.2.1:8388 ifidx: 152
[226089.804390] mptcp_add_sock: token 0xd696d176 pi 4, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.804421] __mptcp_init4_subsockets: token 0xd696d176 pi 4 src_addr:192.168.42.131:0 dst_addr:4.3.2.1:8388 ifidx: 150
[226089.804573] mptcp_add_sock: token 0xd696d176 pi 5, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.804602] __mptcp_init4_subsockets: token 0xd696d176 pi 5 src_addr:192.168.42.162:0 dst_addr:10.47.0.17:8388 ifidx: 149
[226089.804745] mptcp_add_sock: token 0xd696d176 pi 6, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.804775] __mptcp_init4_subsockets: token 0xd696d176 pi 6 src_addr:192.168.42.81:0 dst_addr:10.47.0.17:8388 ifidx: 151
[226089.804912] mptcp_add_sock: token 0xd696d176 pi 7, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.804942] __mptcp_init4_subsockets: token 0xd696d176 pi 7 src_addr:192.168.42.167:0 dst_addr:10.47.0.17:8388 ifidx: 152
[226089.805078] mptcp_add_sock: token 0xd696d176 pi 8, src_addr:0.0.0.0:0 dst_addr:0.0.0.0:0
[226089.805108] __mptcp_init4_subsockets: token 0xd696d176 pi 8 src_addr:192.168.42.131:0 dst_addr:10.47.0.17:8388 ifidx: 150
[226090.054382] mptcp_close: Close of meta_sk with tok 0xd696d176
[226090.143502] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:8 state 7 is_meta? 0
[226090.143551] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:7 state 7 is_meta? 0
[226090.143594] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:6 state 7 is_meta? 0
[226090.143632] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:5 state 7 is_meta? 0
[226090.143747] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:1 state 7 is_meta? 0
[226090.180923] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:3 state 7 is_meta? 0
[226090.186864] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:2 state 7 is_meta? 0
[226090.191985] mptcp_del_sock: Removing subsock tok 0xd696d176 pi:4 state 7 is_meta? 0
[226090.192020] mptcp_sock_destruct destroying meta-sk token 0xd696d176

[SriramScorp]

Looks like in the working device mptcp_add_sock happens for outgoing connections whereas in the device with issues, it is created for incoming connections?

[matttbe]

I think this issue is still related to failure in subflow creation. I have the below logs from another working device (socks server IP and Port obfuscated as 4.3.2.1 and 8388 respectively).

If the network removes MPTCP options, there is nothing the kernel can do. You can use tracebox to identify the origin of the issue and report the issue to the right person/company. https://multipath-tcp.org/pmwiki.php/Users/Tools

it is created for incoming connections?

If I'm not mistaken, it is created for both incoming and outgoing connection. Each time a new subflow is created