Hi @Phil B
I just wanted to know if further assistance might be required on this : )
Looking forward to your feedback,
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Summary of Problem:
We have a Win 10 application (hereafter, “the application/app”) that communicates with an external embedded Linux system (hereafter “the device”) via Wi-Fi. The Wi-Fi connection to the device is provided by an external AP – the PC is connected to that AP via a local ethernet cable from a PCIe NIC.
The app opens several TCP sockets and one UDP socket to the device.
Occasionally, after suffering an unexpected disconnect from the device (e.g., due to poor Wi-Fi signal strength), the application is unable to open the UDP socket to the device (TCP sockets are not affected). We’ve not made much progress on finding root cause, are unable to recreate the problem internally, and the only “fix” we’ve found is to reboot the PC. After that, the UDP socket can again connect.
Note that a full restart of the application has no effect – once the problem has occurred, it remains until the PC is rebooted. A reboot of the device also does not resolve the issue. For these and other reasons discussed below, we believe the problem is on the PC, not on the device.
Details:
Socket code in both the app and device has been able to reliably maintain and handle asynchronous disconnects (i.e., disconnects don’t prevent reconnection) without issue for years until this recent UDP socket problem. And we’ve been unable to attribute this problem to code changes - none of the relevant code has been modified for at least 6 years (per VCS history).
Our application has a DLL back end that communicates with the device. These DLLs are written in C++ and rely on the winsock API for networking.
The problem of being unable to open the UDP socket has a specific error signature and always occurs in the same way. What follows is an overview of the code path that leads to the error. Note that the C++ back end preforms all available error checking on return values from calls into the winsock library.
Version Information:
Our products use Windows 10’s Long-Term Servicing Channel, and we had no issues when running Windows 10 IoT Enterprise LTSB 2016 (10.0.14393). We first began hearing reports of this issue shortly after we introduced Windows 10 IoT Enterprise LTSC 2019 (10.0.17763) – specifically, 10.0.17763.1757, with ws2_32.dll version 10.0.17763.771.
Misc. Information:
Or did you mean a Hub device which is different than a dump switch?
Looking forward to your feedback.
Cheers,
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.
Hello @Phil B
Thank you for that excellent explanation given previously.
I can not deny that this brought my attention and I would like to add some relevant steps or comment on this.
Looking forward to your feedback.
Cheers,
Please "Accept the answer" if the information helped you. This will help us and others in the community as well.