How to Receive Packet but Not Upload
Windows Networking Troubleshooting ane: Not Receiving Data Packets at NIC
It is frequently difficult to troubleshoot problems involving sending and receiving packets. This series of articles focus on network troubleshooting and summarizes troubleshooting procedures and analysis results to gradually provide a complete and deep analysis and written report of NDIS (Network Driver Interface Specification) Framework and Qemu Virtio netkvm.
Trouble
When Windows Server uses FTP to upload files, network exceptions are thrown during transmission, causing file manual failures. Although the server network automatically recovers itself afterwards a while, this problem oft recurs during subsequent upload operations.
Collect Basic Information
Although the trouble seems very articulate, we need to empathise more details:
1. The condition that triggers the network exceptions: On some other client, utilise FTP to upload files.
2. Network exception diagnosis:
- Enter ping 127.0.0.i on this auto and the outcome is normal. This indicates that the TCP/IP protocol stack is working usually and that the problem lies in the underlying drivers. If the result of this control is abnormal, more often than not nosotros utilise netsh.exe to reset TCP/IP and Winsock.
- This is a classical network host. When the problem occurs, the network interface controller (NIC) for the intranet is working correctly. Specifically, ping this Windows Server on machines with the same intranet network segment and the result is normal. Ping the intranet DNS through the intranet NIC and the outcome is also normal.
- When the problem occurs, this machine tries to ping the gateway configured on the NIC for the Net and finds that information technology is not continued. Step two and Step three indicate that the NIC driver is working equally expected. The problem may lie in the Internet NIC or its corresponding NDIS Miniport, including the NDIS_MINIPORT_BLOCK construction maintained by NDIS.sys and the _ADAPTER construction maintained by the NIC driver.
- When we ping the gateway, the outcome of running ARP -a shows that the mapping between the MAC of the gateway and IP is incomplete. This indicates that sending data packets has already triggered ARP merely response cannot be received.
- Based on Step 4, nosotros check the NIC device and find that the status is normal. Even so, the NIC backdrop (Network Connection -> NIC Properties) testify that the count of sent packets has increased just that the received packets have not increased. This indirectly reflects that the ARP asking is properly sent but no response is received.
- Finally, nosotros disable then enable the NIC, and detect that this problem is actually solved.
3. Based on the previous network exception diagnosis, we roughly know that this problem has something to do with ARP. However, later adding static ARP information (arp.exe -southward gw.ipv4.accost ee:ff:ff:ff:ff:ff) past using arp.exe -s, we find that we notwithstanding cannot ping the gateway, which means that ARP is non the just reason.
Locate the Problem
To locate the trouble more accurately, we perform packet capture and analysis on both the Windows automobile and its host. Unfortunately, the captured packets are straight printed on the screen. No specific packet content is retained. Screenshots of subsequent packet capture operations will be bachelor in similar scenarios.
Hither is the event of the packet capture assay. After static ARP is added, the result of the packet capture on the VIF interface shows that the pinged ICMP Echo Request bulletin is sent from the VIF interface and the ICMP Repeat Answer message is received.
Based on the preceding tests and diagnosis, we recollect that this problem lies in the underlying driver. We tin capture and analyze the dump file in Windows directly from NC.
Tips
Windows has integrated packet capture capability since 2008 R2. This capability is implemented on NDIS.sys and works with the ETW mechanism on Windows to make troubleshooting easier and more convenient. To enable this capability, just run the post-obit command:
netsh trace showtime capture=yes After the problem recurs, run the post-obit command:
netsh trace stop Captured log files are written into the temp directory of the electric current user. Afterwards we run the stop command, Windows volition impress the path to the log file in cmd.exe.
The file that this control captures can be opened with Microsoft Network Monitor 3.iv or Microsoft Message Analyzer. Currently Wireshark cannot recognize this file.
ETW (Event Tracing for Windows) is a skilful tool to troubleshoot Os component behaviors. Windows provides some ready-to-use scenarios and providers, which we tin can view by using netsh trace show scenarios and netsh trace testify providers. Perhaps I will write a separate commodity to describe these available scenarios and providers afterwards. Regarding networking, I list some providers related to NDIS, TCP/IP, Afd, and Winsock here. These providers are applicative for deep analysis of system network behaviors in general scenarios. The command is as follows.
netsh trace start provider={2F07E2EE-15DB-40F1-90EF-9D7BA282188A} keywords=0xffffffffffffffff level=0xff provider={E53C6823-7BB8-44BB-90DC-3F86090D48A6} keywords=0xffffffffffffffff level=0xff provider={7D44233D-3055-4B9C-BA64-0D47CA40A232} keywords=0xffffffffffffffff level=0xff provider={50B3E73C-9370-461D-BB9F-26F32D68887D} keywords=0xffffffffffffffff level=0xff provider={43D1A55C-76D6-4F7E-995C-64C711E5CAFE} keywords=0xffffffffffffffff level=0xff maxSize=500MB fileMode=circular persistent=no overwrite=yes report=yes correlation=yes traceFile=c:\NetworkTrace.etl capture=yes packettruncatebytes=128 IPv4. Address=<ipv4.address.for.filtering> To learn more than about the significant of the control, see the netsh trace capture assist.
Retentivity Dump Analysis
Commencement, check the condition of the NIC Miniport. Information technology shows no exceptions. If a NIC is abnormal, we may typically look at full general information similar Awaiting OID or Reset. In this case, we can endeavor to upgrade the NIC commuter.
Side by side, bank check the send path, that is, information nigh sending request. In older versions of Windows, we tin see the reference on mopen. Each fourth dimension a request is sent, the tcpip.sys driver increases the reference of mopen for both TCP/IP and Miniport. After a message is sent, the NIC volition invoke the callback role in the tcpip.sys driver to release the reference.
In versions later than Windows Server 2008 R2, the reference of mopen does non work any more. The count of sent requests is recorded in the Provider_Rundown_Protection of tcpip.sys to meet the capability of processing a sending request on unlike CPUs. The count in the Rundown targets each CPU. Addition and subtraction are performed to determine whether all pending NBLs have been sent.
References
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-exinitializerundownprotection
Observe the status information about sending and receiving requests by using the counts of other statuses. We observe the statistics of Virtio netkvm and confirm that both sending and receiving is normal.
Later on further checking the data structure, we find that the NetReceiveBuffer List is empty and that NetNofReceiveBuffers is 0. This may happen because the NIC driver finds no buffer available, leading to the pause of receiving packets. We have dissimilar options for the netkvm commuter. For example, we can disable the NIC to forestall packet reception when the buffer is full.
Next, check the ParaNdis_ProcessRxPath role and the virtqueue_get_buf function to confirm that the ring buffer is full.
The Virtio netkvm code shows that the buffer content in the LIST_ENTRY information structure of NetReceiveBuffersWaiting is maintained by the Windows NDIS framework driver. The ReturnPacketHandler that the netkvm commuter has registered (that is, netkvm) is invoked. ParaNdis5_ReturnPacket releases the buffer and returns the content to NetReceiveBuffers.
At this betoken, the central issue is why NDIS does non invoke the callback part. Windows mainly depends on the references (namely, the reference count) of the NET_BUFFER_LIST data construction to recycle buffer related to the NIC. If the buffer is used, its reference count will be increased by 1. If the buffer operation is completed, the commuter respective to the reference will invoke Dereference to release the reference. The callback role will exist invoked simply when the reference count of the buffer becomes 0.
We can troubleshoot this trouble by enumerating all unreleased buffers and printing the network packet structure. For example:
! listing "-t \_LIST\_ENTRY.Flink -e -x \"dt netkvm! IONetDescriptor @$extret; dt ndis! _NDIS_PACKET poi(@$extret+0x40) Private.; dt _MDL poi(poi(@$extret+0x40)+8); db poi(poi(poi(@$extret+0x40)+8)+0x18) L0x50\" 0xfffffadf`37fa26d0" 
Note: 0x0bda = 3034 is the data port used in the FTP Pasv manner.
In this instance, the Serv-U FTP server does not process bundle receipt, causing the buffer to be full. This trouble tin be solved by using the build-in IIS FTP in Windows.
Conclusion
Based on the previous assay, we can more often than not make the following plans:
1. The NDIS driver on Windows itself is not properly releasing the buffer. Nosotros recommend that you install the latest ndis.sys patch.
2. Other tertiary-party drivers have incorrect references to the buffer, resulting in the reference count unable to be 0. It is recommended to uninstall third-party drivers and continue the operating system make clean.
iii. Messages are not processed.
- Possible crusade 1: After packets are received, they need to be indicated to the upper-layer application through the messaging mechanism. Slow indication or deadlock may cause problems.
- Possible cause ii: The awarding has a Critical Section, which prevents the recv operation. Any issues between tcpip.sys, afd.sys, Winsock, and applications themselves volition cause network problems.
It is generally recommended to upgrade the tcpip.sys, afd.sys, and winsock components, and replace the current application with other software.
-
-
Tim Chen
8 posts | one followers
Follow
Yous may also like
Comments
-
-
Tim Chen
eight posts | one followers
Follow
Related Products
-
Networking Overview Connect your concern globally with our stable network anytime anywhere.
Learn More -
Accelerated Global Networking Solution for Altitude Learning Alibaba Cloud offers an accelerated global networking solution that makes distance learning just the aforementioned every bit in-class teaching.
Learn More -
Global Network Solution Alibaba Cloud'southward global infrastructure and cloud-native SD-WAN technology-based solution can help you build a dedicated global network
Larn More than -
Quick Starts Deploy custom Alibaba Cloud solutions for business-critical scenarios with Quick Start templates.
Larn More
Source: https://www.alibabacloud.com/blog/windows-networking-troubleshooting-1-not-receiving-data-packets-at-nic_594837
0 Response to "How to Receive Packet but Not Upload"
Post a Comment