Issue also presents on ARM64 RHEL9.3 - kernel 5.14.0-316.el9.aarch64.

+++ This bug was initially created as a clone of Bug #2211258 +++

Description of problem:
TCP transport should be able to tolerate mild channel corruption (0.5%). Yet the md5sum value doesn't match when sending a ~500MB file.

Version-Release number of selected component (if applicable):
4.18.0-492.el8.aarch64

How reproducible:
100%

Steps to Reproduce:
Detailed steps are filed in below Polarion cases:
https://polarion.engineering.redhat.com/polarion/#/project/RHELVIRT/workitem?id=VIRT-80160
https://polarion.engineering.redhat.com/polarion/#/project/RHELVIRT/workitem?id=VIRT-80159

Actual results:
File size matches but not md5sum

1. ls -al server_data
   rw-rr-. 1 root root 524288000 May 30 04:22 server_data
2. md5sum server_data
   17da58d5050b0a58e3a44685e2b9d522 server_data
3. ls -al client_data
   rw-rr-. 1 root root 524288000 May 30 04:22 client_data
4. md5sum client_data
   7bb64858c2801de10cac8abe4a8968f0 client_data
   Expected results:
   md5sum value matches.

Additional info:
1. x86_64 does not have this issue.
2. Both IPv4 and IPv6 have this issue.
3. No such issue without channel corruption.

— Additional comment from Li Tian on 2023-05-31 11:19:47 CST —

In case people can't view Polarion links, here are the steps:

1. Create 2 VMs on Azure. And make sure checksum offload is turned on -

1. ethtool -k eth0|grep checksum

2. Install below packages -
nmap-ncat iproute-tc kernel-modules-extra

3. On VM#1 open a listen port with 'nc' -

1. nc -l 2233 > server_data

4. On VM#2 create a 0.5% channel corruption -

1. tc qdisc add dev eth0 root netem corrupt 0.5%
   Then generate a 500MB file and send to VM#1 -
2. dd if=/dev/urandom of=client_data bs=1024k count=500; nc <VM#1_IP> 2233 < client_data

5. Compare md5sum value on 'server_data' and 'client_data'.