N
nola2172
Guest
Short version of below - we can't seem to successfully send UDP packets larger than 1472 bytes when running Build 1809 of Windows, though it worked OK in previous versions.
We have an existing C# application (really a set of applications) that runs on a local wired network that periodically sends out UDP packets to communicate status to other applications on different computers on the network. Some of these packets are small, but some are fairly large. This application is written in C# using .NET 4.5.1 and uses the UdpClient class to broadcast and receive broadcasts. Prior to testing with Windows 10 build 1809 / Windows Server 2019 build 1809, everything worked fine - we sent and received the larger packets without a problem. However, starting with build 1809, it appears that we can no longer successfully send the large packets. Here is some of the testing that we did:
System 1: Windows 10 Build 1803 (MTU is 1500)
System 2: Windows 10 Build 1809 (MTU is 1500)
I wrote a test program that sends out a small (200 bytes or so) and large (8000 bytes or so) UDP packet using UdpClient, while also listening for those packets. Here is what happens when I send from each system:
-Send from System 1:
-System 1 sees both packets
-System 2 sees both packets
-Send from System 2:
-System 1 sees only the small packet
-System 2 sees both packets
This happens every single time - the large packets never arrive successfully. Further testing revealed that the magic number was 1472 bytes. That or less worked, and more than that failed. This is why I suspect that something with fragmenting/MTU is not working correctly. We had not seen this problem before, so I fired up Wireshark to take a look at what might be going on. However, and this is where it gets weird, starting Wireshark on the Build 1809 system suddenly makes it able to send the packet, even if I exit Wireshark. Rebooting the system, though, reverts it to its original state of being unable to send successfully. I should note that I always see "Fragmented IP Protocol" for these packets in Wireshark on the receiving end of things regardless of whether they are working correctly or not.
I did some reading online and found that RDP over UDP had a major overhaul in Build 1809, but I did not see anything about UDP packets larger than the MTU having a problem, nor was I able to find anyone else reporting this particular issue.
We have made no code changes to this part of our code in a long time - it worked on Windows 7, Server 2012R2, Server 2016, and Windows 10 prior to build 1809. Is there something new in Build 1809 that requires us to set a flag somewhere or configure something on the network adapter? I don't know what all Wireshark does when it boots up, but it seems to "fix" things somehow, so if anyone has an idea what that might be specifically that could help as well.
As an additional note - I did make sure my network drivers were up to date, and one of the systems was a Windows 10 VM running 1803 that I upgraded to 1809. It worked OK as 1803 and immediately stopped working correctly after the update to 1809.
Continue reading...
We have an existing C# application (really a set of applications) that runs on a local wired network that periodically sends out UDP packets to communicate status to other applications on different computers on the network. Some of these packets are small, but some are fairly large. This application is written in C# using .NET 4.5.1 and uses the UdpClient class to broadcast and receive broadcasts. Prior to testing with Windows 10 build 1809 / Windows Server 2019 build 1809, everything worked fine - we sent and received the larger packets without a problem. However, starting with build 1809, it appears that we can no longer successfully send the large packets. Here is some of the testing that we did:
System 1: Windows 10 Build 1803 (MTU is 1500)
System 2: Windows 10 Build 1809 (MTU is 1500)
I wrote a test program that sends out a small (200 bytes or so) and large (8000 bytes or so) UDP packet using UdpClient, while also listening for those packets. Here is what happens when I send from each system:
-Send from System 1:
-System 1 sees both packets
-System 2 sees both packets
-Send from System 2:
-System 1 sees only the small packet
-System 2 sees both packets
This happens every single time - the large packets never arrive successfully. Further testing revealed that the magic number was 1472 bytes. That or less worked, and more than that failed. This is why I suspect that something with fragmenting/MTU is not working correctly. We had not seen this problem before, so I fired up Wireshark to take a look at what might be going on. However, and this is where it gets weird, starting Wireshark on the Build 1809 system suddenly makes it able to send the packet, even if I exit Wireshark. Rebooting the system, though, reverts it to its original state of being unable to send successfully. I should note that I always see "Fragmented IP Protocol" for these packets in Wireshark on the receiving end of things regardless of whether they are working correctly or not.
I did some reading online and found that RDP over UDP had a major overhaul in Build 1809, but I did not see anything about UDP packets larger than the MTU having a problem, nor was I able to find anyone else reporting this particular issue.
We have made no code changes to this part of our code in a long time - it worked on Windows 7, Server 2012R2, Server 2016, and Windows 10 prior to build 1809. Is there something new in Build 1809 that requires us to set a flag somewhere or configure something on the network adapter? I don't know what all Wireshark does when it boots up, but it seems to "fix" things somehow, so if anyone has an idea what that might be specifically that could help as well.
As an additional note - I did make sure my network drivers were up to date, and one of the systems was a Windows 10 VM running 1803 that I upgraded to 1809. It worked OK as 1803 and immediately stopped working correctly after the update to 1809.
Continue reading...