You're right, it's weird...
I tried to see if I could reproduce this behaviour when
in bidirectional with different MTU values, and things are a bit different...
Allways the same command is issued on the "A" side (sender) :
Code: Select all
ping -s 38787 10.0.0.56
PING 10.0.0.56 (10.0.0.56) 38787(38815) bytes of data.
38795 bytes from 10.0.0.56: icmp_seq=1 ttl=64 time=2.36 ms
With MTU = 2000 bytes
On the sender side ("A") :
Code: Select all
--- 10.0.0.56 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 8ms
On the receiver side ("B") :
Code: Select all
sudo tcpdump -i enp2s0 icmp -vv
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:01:32.721639 IP (tos 0x0, ttl 64, id 49562, offset 0, flags [+], proto ICMP (1), length 1996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3417, seq 1, length 1976
09:01:32.721697 IP (tos 0x0, ttl 64, id 49562, offset 1976, flags [+], proto ICMP (1), length 1996)
10.0.0.55 > 10.0.0.56: icmp
09:01:32.721702 IP (tos 0x0, ttl 64, id 49562, offset 3952, flags [+], proto ICMP (1), length 1996)
10.0.0.55 > 10.0.0.56: icmp
09:01:32.721706 IP (tos 0x0, ttl 64, id 49562, offset 5928, flags [+], proto ICMP (1), length 1996)
10.0.0.55 > 10.0.0.56: icmp
[...]
25 packets captured
120 packets received by filter
95 packets dropped by kernel
We see that the fragments look right (1996)
With MTU = 3000 bytes
On the sender side ("A") :
Code: Select all
--- 10.0.0.56 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
On the receiver side ("B") :
Code: Select all
sudo tcpdump -i enp2s0 icmp -vv
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:02:38.135827 IP (tos 0x0, ttl 64, id 55577, offset 0, flags [+], proto ICMP (1), length 2996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3421, seq 1, length 2976
09:02:38.135869 IP (tos 0x0, ttl 64, id 55577, offset 2976, flags [+], proto ICMP (1), length 2996)
10.0.0.55 > 10.0.0.56: icmp
09:02:38.135875 IP (tos 0x0, ttl 64, id 55577, offset 5952, flags [+], proto ICMP (1), length 2996)
10.0.0.55 > 10.0.0.56: icmp
09:02:38.135879 IP (tos 0x0, ttl 64, id 55577, offset 8928, flags [+], proto ICMP (1), length 2996)
10.0.0.55 > 10.0.0.56: icmp
[...]
14 packets captured
56 packets received by filter
42 packets dropped by kernel
1 packet dropped by interface
We see that the fragments look normal whereas in unidirectional mode packet size droped to 127 bytes!
Maybe there's a sort of negociation?
With MTU = 9000 bytes
On the sender side ("A") :
Code: Select all
--- 10.0.0.56 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 11ms
On the receiver side ("B") :
Code: Select all
sudo tcpdump -i enp2s0 icmp -vv
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:03:23.823999 IP (tos 0x0, ttl 64, id 56213, offset 0, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3424, seq 1, length 8976
09:03:23.824063 IP (tos 0x0, ttl 64, id 56213, offset 8976, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: icmp
09:03:23.824071 IP (tos 0x0, ttl 64, id 56213, offset 17952, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: icmp
09:03:23.824077 IP (tos 0x0, ttl 64, id 56213, offset 26928, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: icmp
09:03:23.824082 IP (tos 0x0, ttl 64, id 56213, offset 35904, flags [none], proto ICMP (1), length 2911)
10.0.0.55 > 10.0.0.56: icmp
09:03:23.824190 IP (tos 0x0, ttl 64, id 19490, offset 0, flags [+], proto ICMP (1), length 8996)
10.0.0.56 > 10.0.0.55: ICMP echo reply, id 3424, seq 1, length 8976
09:03:23.824198 IP (tos 0x0, ttl 64, id 19490, offset 8976, flags [+], proto ICMP (1), length 8996)
10.0.0.56 > 10.0.0.55: icmp
[...]
15 packets captured
20 packets received by filter
5 packets dropped by kernel
Here again, this time fragments look normal with the "ping -s 38787 10.0.0.56" command.
With this same MTU value, if I now try
with greater packet size (
65500), this time it gets worst:
On the sender side ("A") :
Code: Select all
ping -s 65500 10.0.0.56
PING 10.0.0.56 (10.0.0.56) 65500(65528) bytes of data.
^C
--- 10.0.0.56 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 159ms
On the receiver side ("B") :
Code: Select all
sudo tcpdump -i enp2s0 icmp -vv
tcpdump: listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:19:47.792275 IP (tos 0x0, ttl 64, id 36270, offset 0, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3495, seq 1, length 8976
11:19:47.792335 IP (tos 0x0, ttl 64, id 36270, offset 8976, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: icmp
11:19:47.792343 IP (tos 0x0, ttl 64, id 36270, offset 17952, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: icmp
[...]
11:26:08.272261 IP (tos 0xc0, ttl 64, id 19228, offset 0, flags [none], proto ICMP (1), length 576)
10.0.0.56 > 10.0.0.55: ICMP ip reassembly time exceeded, length 556 <--- /!\
IP (tos 0x0, ttl 64, id 60642, offset 0, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3504, seq 2, length 8976
11:26:08.272323 IP (tos 0xc0, ttl 64, id 19229, offset 0, flags [none], proto ICMP (1), length 576)
10.0.0.56 > 10.0.0.55: ICMP ip reassembly time exceeded, length 556 <--- /!\
IP (tos 0x0, ttl 64, id 60495, offset 0, flags [+], proto ICMP (1), length 8996)
10.0.0.55 > 10.0.0.56: ICMP echo request, id 3504, seq 1, length 8976
11:26:08.420757 IP (tos 0x0, ttl 64, id 64572, offset 0, flags [+], proto ICMP (1), length 8996)
[...]
^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel
This time, packets still have a correct size but they are not reconstructed on the receiver side as the sender side displays 100% icmp requets lost and we can see "ICMP ip reassembly time exceeded" messages in the tcpdump output.
I finally tried this "ping -s 65500 10.0.0.56" command with a regular MTU=1500 on both sides and could observe the same (near 100% icmp packet lost and the "ICMP ip reassembly time exceeded" message from time to time).

I don't see if the problem comes from the Realtek NIC or the driver but I guess it's one of these two. Do you share my assumption?