Re: apropos https://github.com/multipath-tcp/mptcp_net-next/issues/265

[Mat Martineau <mathew.j.martineau@linux.intel.com>]

On Tue, 3 May 2022, Maxim Galaganov wrote:

> On 29.04.2022 13:08, Paolo Abeni wrote:
>> I think should see sistematic csum failure when the involved peers have
>> different endianess (e.g. x86 vs arm). If anyone has easy access to
>> both systems, could please verify the above?
>> 
>
> I've built OpenWrt from current master (4509b79) for ath79/generic with 
> CONFIG_TESTING_KERNEL=y
> CONFIG_MPTCP=y
> CONFIG_MPTCP_IPV6=y
>
> and flashed it onto TP-Link Archer C7 v5.
> This is what I can observe with a simple echo server and nc.
>
> Client:
> % uname -r
> 5.17.4-200.fc35.x86_64
> % lscpu |fgrep ndian
> Byte Order:                      Little Endian
> % mptcpize run nc 192.168.2.1 12345
> qwerty
> Ncat: Connection reset by peer.
>
> Server:
> root@tpa3:~# uname -r
> 5.15.35
> root@tpa3:~# lscpu |fgrep ndian
> Byte Order:          Big Endian
> root@tpa3:~# sysctl -w net.mptcp.checksum_enabled=1
> net.mptcp.checksum_enabled = 1
> root@tpa3:~# ./echo 12345
> Server is listening on 12345
> ^C
> root@tpa3:~# nstat 'Mptcp*'
> #kernel
> MPTcpExtMPCapableSYNRX          1                  0.0
> MPTcpExtMPCapableACKRX          1                  0.0
> MPTcpExtDataCsumErr             1                  0.0
> MPTcpExtMPFailTx                1                  0.0
>
> The issue goes away when I set net.mptcp.checksum_enabled=0 on both ends. 
> Please tell me if you need more info.
>

Hi Maxim -

Thanks for verifying the problem and that it does appear to interop when 
checksums are off.

I found some helpful notes from the BPF maintainers on setting up a 
big-endian s390x qemu guest:

https://www.kernel.org/doc/html/latest/bpf/s390.html

Hopefully that will allow us to set up some vms for ongoing testing. I'm 
working on setting one up to experiment with.

--
Mat Martineau
Intel