Score:0

Ping with jumbo frames fail but returns default ping fail message

ec flag

I need to set up a local connection between my Windows 11 PC and an external device (IP 10.0.0.10), with jumbo frames enabled (MTU 9000). The end goal on my PC is to connect to the remote device from WSL2, which currently works but has the same MTU issues.

At the end of the post, I put the steps I followed to set the MTU.

However, I still cannot ping my device with a large packet size. The strange thing is that I get a default ping fail message, and not a packet too large ping fail message.

To compare, let me show you the result of a normal ping (#1), a ping with a packet too large (#2), and a ping with a packet that should be handled by the jumbo frame (#3).

  • On Powershell:
# 1.
ME> ping 10.0.0.10
Envoi d’une requête 'Ping'  10.0.0.10 avec 32 octets de données :
Réponse de 10.0.0.10 : octets=32 temps<1ms TTL=64

# 2.
ME> ping 10.0.0.10 -f -l 10000
Envoi d’une requête 'Ping'  10.0.0.10 avec 10000 octets de données :
Le paquet doit être fragmenté mais paramétré DF.

# 3. 
ME> ping 10.0.0.10 -f -l 8200
Envoi d’une requête 'Ping'  10.0.0.10 avec 8200 octets de données :
Délai d’attente de la demande dépassé.
Statistiques Ping pour 10.0.0.10:
    Paquets : envoyés = 1, reçus = 0, perdus = 1 (perte 100%),
  • On WSL2 (same results):
# 1.
~$ ping 10.0.0.10
PING 10.0.0.10 (10.0.0.10) 56(84) bytes of data.
64 bytes from 10.0.0.10: icmp_seq=2 ttl=64 time=1.49 ms

# 2.
~$ ping 10.0.0.10 -c 10 -M do -s 10000
PING 10.0.0.10 (10.0.0.10) 10000(10028) bytes of data.
ping: local error: message too long, mtu=9000

# 3. 
~$ ping 10.0.0.10 -c 10 -M do -s 8900
PING 10.0.0.10 (10.0.0.10) 8900(8928) bytes of data.
--- 10.0.0.10 ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9368ms

To summarize, #1 returns a ping, #2 returns a packet too large error, and #3 returns a default error. As you see, behavior #1 and #2 are normal, but not #3. The packet size is not too big to be handled by MTU (or else, I would have had the same error as #2).

I looked this problem up online and the answer I found was: my PC is configured correctly, but the receiving device does NOT have a MTU big enough. However, this device is specifically made to handle these large packets, I contacted the device's maker and they told me that it natively handles jumbo frames.

Where does this problem come from and what can I do to send large packets to 10.0.0.10 ?

The problem seems to be on my connection, but I can't find anything.


Steps followed to set MTU

  1. Powershell:
PS C:\Users\me> Set-NetAdapterAdvancedProperty "Ethernet*" -DisplayName "Jumbo Packet" -RegistryValue "9014"
PS C:\Users\me> Get-NetAdapterAdvancedProperty
Name                      DisplayName                    DisplayValue                   RegistryKeyword RegistryValue
----                      -----------                    ------------                   --------------- -------------
(...)
Ethernet 4                Jumbo Packet                   9014 Bytes                     *JumboPacket    {9014}
(...)
  1. Command line:
netsh interface ipv4 set subinterface "Ethernet 4" mtu=9000 store=persistent
netsh interface ipv4 show subinterfaces

       MTU  État détect supp      Octet entrant     Octet sortant  Interface
----------  ---------------  ------------  ------------  -------------
(...)
      9000  5             0             0  Ethernet 4 - Adaptateur TPL Blanc
(...)

  1. ncpa.cpl (Network administration tool):
  • Ethernet 4 --> configure --> advanced --> Jumbo Packets --> 9000
  1. WSL:
~$ sudo ifconfig eth0 mtu 9000 up
~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 10.0.0.3  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::215:5dff:fe8a:1792  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:8a:17:92  txqueuelen 1000  (Ethernet)
        RX packets 74  bytes 12574 (12.5 KB)
        RX errors 0  dropped 3  overruns 0  frame 0
        TX packets 34  bytes 92254 (92.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
djdomi avatar
za flag
jumbo frames never solved the problem that a bandwidth increases could fix
Score:0
in flag

You don’t mention the exact network topology between your machine and the remote one, but every network device in the path has to either support jumbo frames (and that has to be actually enabled) or be configured to allow fragmentation of the packet so it will fit in a smaller frame size.

The best troubleshooting strategy would be a packet capture as close to the remote device as possible. Make sure that a large ping is actually making it from your source machine to the remote device, and see whether the remote device responds or not.

Another troubleshooting idea is to put a machine you control on the same network segment as the remote device, and set its MTU accordingly. Then you can check that the network itself will support jumbo frames as you expect.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.