timeout when ping target with 85 bytes

liujia 6 Reputation points


A hosting produce - C2338 CPU with Intel I120 network adpater installed Windows 2019. When I ping it from Internet with default 32 bytes, it is okay. But time out when using 85 or more bytes. How to find out why package was dropped?

Pinging with 32 bytes of data:  
Reply from bytes=32 time=283ms TTL=114  
Reply from bytes=32 time=284ms TTL=114  

But with 85 or more bytes of data was 'Time out'

Pinging with 85 bytes of data:  
Request timed out.  
Request timed out.  
Request timed out.  
Request timed out.  
Ping statistics for  
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)  

If I run mtupath.exe, it shows

MTU path scan to, ttl=64, limit=48  
# 26 best MSS 84 (estimated MTU 112) [pPPPP****p*p**ppP**P**P***]  
        #1 MSS IN RANGE     1 <==    83 ==>    84  
        #2 SCAN TIMEOUT    85 <==  1379 ==>  1464  
        #3 MSS EXCEEDED  1465 <== 14919 ==> 16384  
[WARNING] Minimum IPv4 Internet MTU of 576 was not reached  
[WARNING] Possible PMTU blackhole in route to peer  

Why this server's MTU has limited to 112 bytes?

I installed latest NIC driver from Intel or Windows update, it did not help. I have disabled Windows Firewall, but nothing was chagned. I tried to run 'netsh wfp show netevents', but there is no related block events by wfp too. If changed server from Windows 2019 to Linux, everyting is okay.

If package did not drop on network layer, it is possible happen on physical layer or data link layer? How to check or debug if package drop on them? Refer: https://learn.microsoft.com/en-us/windows-hardware/drivers/network/windows-network-architecture-and-the-osi-model

Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management, data storage, applications, and communications.
2,629 questions
0 comments No comments
{count} votes

3 answers

Sort by: Most helpful
  1. Limitless Technology 37,741 Reputation points

    Hello @liujia

    1. Please try to ping with different public ip address from this 2019 server.
    2. Please try to ping with ip from different machine having different subnet to check if there is any request time out.
    3. Please check if you any VLAN configurations or NAT rules in placed at gateway or firewall level.
    4. Try swap internal ip of Windows 2019 with Linux system to see if there are any firewall rules for static ip.


    --If the reply is helpful, please Upvote and Accept as answer--

    0 comments No comments

  2. Gary Reynolds 8,931 Reputation points

    Hi @liujia

    Have you try to repeat the test from a machine on the same network, rather than across the internet?

    Some firewalls and routes support a feature to limit the maximum size of a ICMP packet that they will forward, this is to limit the potential for DDoS attacks. The details of the tests you have run above are all based on ICMP. Have you completed any tests that use TCP or UDP?

    Are you seeing a problem with the service you are planning to run on the server?


  3. Gary Reynolds 8,931 Reputation points

    Hi @liujia

    With the packet captures we have completed so far, we are capturing the packets seen by the network stack and not what has been transmitted on the wire. Really we need to see what is being sent by the server on the wire but without another machine, or help from your hosting company I'm not sure we will be able to get any more information.

    I've seen weird networking issues before that are caused by the offload features in the driver, I think the next thing to try is to disable all the optimization features in the network card driver properties and see if this fixes the issue.

    Based on the Intel i210 network card and this page ethernet-products.html I would recommend that you disable the following settings:

    Jumbo frames (jumbo packets)
    Large send offload
    Adaptive inter-frame spacing
    Flow control
    Interrupt moderation rate - Off
    Receive Side Scaling
    IPv4 checksum offload
    TCP checksum offload
    Offload transmit IP checksum
    UDP checksum offload

    I would check that the transmit and receive buffer settings I wuld try increasing them, but also set them to 0 and see if this makes any difference.

    I know your hosting company has told you that the server is a Dell, but I can't find any information
    on Dell server\machines that having Intel Atom C3250 processor, but that might be because the processor was released back in 2013. The other thing that doesn't make sense is that the MAC address of your machine is associated to ADI Engineering and not Intel. ADI Engineering specialise in embedded single board computers, which might explain why your hosting company has said that it doesn't support Windows as the board might not be tested or certified for Windows. May be ask them.

    Give the network options a try and see if that fixes the problem, if not, then my suggestion would to send a network capture of the issue to the hosting company and try to get them to do a packet capture from the router or another machine on the network segment to see what is being transmitted by the server when you have an ICMP over 85 bytes.