3

I've got a Windows application that receives and processes XML messages transmitted via UDP. The application collects the data using Windows "raw" sockets, so the entire layer 3 packet is visible.

We've recently run across a problem that has me stumped.

If the XML messages (i.e., UDP packets) are large (i.e., > 1500 bytes), they get fragmented as expected. Ordinarily, this will cause the XML processor to fail because it attempts to process each UDP packet as if it is a complete XML message. This is a known short-coming in the system at this stage of its development.

On Windows 7, this is exactly what happens. The fragments are received and logged, but no processing occurs. On Windows XP, however, the same fragments are seen, and the XML processor seems to handle everything just fine.

Does Windows XP automatically reassemble UDP fragments? I guess I could expect this for a normal UDP socket, but it's not expected behavior for a "raw" socket, IMO. Further, if this is the case on Windows XP, why isn't the behavior the same on Windows 7? Is there a way to enable this?

Matt Davis
  • 133
  • 1
  • 1
  • 5
  • When you say "fragmented" do you mean a single XML message winds up in multiple UDP datagrams? Or do you mean a single UDP datagram fragments into multiple IP packets? – David Schwartz Jun 18 '12 at 20:30
  • 4
    The short answer to this question is "When you break the rules, sometimes it works by sheer luck. But if you just follow the rules, you won't have to worry about it." – David Schwartz Jun 18 '12 at 20:31
  • @David Schwartz, break what rules? – Matt Davis Jun 18 '12 at 21:47
  • @David Schwartz, a single send of the XML message winds up in two (in this case) IP packets. – Matt Davis Jun 18 '12 at 21:49
  • The rule that applications should access the UDP layer through the UDP interface, not through the raw interface unless those applications intend to replicate all of the UDP and IP layer's logic. – David Schwartz Jun 18 '12 at 23:22
  • @MattDavis: you may want to perform a packet capture to determine if the Windows 7 machine is sending any useful ICMP information back. Such as "Fragment Reassembly Time Exceeded". – Greg Askew Jun 19 '12 at 11:29
  • @MattDavis: if I understand correctly, packet fragmentation and reassembly happens in the IPv4 layer, it isn't related to any particular IP protocol such as UDP. Therefore, I think it's entirely up to each specific socket implementation whether or not packets are reassembled before being passed to raw sockets. This means it shouldn't be particularly surprising if different versions of Windows behave differently in this respect. – Harry Johnston Jun 19 '12 at 22:36

1 Answers1

2

it sounds like the bug is in the way the XML processor is obtaining the UDP datagrams. It should not be looking at packets at all. That's the UDP stack's job.

The XML processor should be asking the UDP layer for re-assembled UDP datagrams. Splitting datagrams into packets and then reassembling those packets into datagrams is the IP and UDP stack's job.

Obviously, if you use raw sockets, UDP will break if you don't replicate this behavior. But don't use raw sockets, use UDP that way it was intended to be used.

When you intercept packets through the raw interface, whether you get them before or after IP reassembly depends on a number of system parameters such as what firewalls are enabled and what rules they have. Your code "happens to work" if it gets the raw packets after IP re-assembly. But relying on this is broken. if re-assembly is not needed, it will not happen, and it is not always needed.

David Schwartz
  • 31,215
  • 2
  • 53
  • 82
  • Right now, our system does not reassemble the UDP packets after collecting them via the raw socket. You're right. This is a bug in our system, a known shortcoming. It only rears its head when another system sends us 'large' messages, like these XML messages we're currently focused on. What I do not understand is why the messages are processed fine on Windows XP but not on Windows 7. The XML processor has no special logic to behave differently based on OS, so I would expect the XML processing to fail on both systems. But it seems to work on Windows XP. ??? – Matt Davis Jun 18 '12 at 23:40
  • They're not processed fine on Windows 7 because you are bypassing the UDP stack's reassembly logic. Retrieving them via the raw socket and then not doing UDP datagram reassembly is totally broken. If you bypass the UDP stack, *you* have to do its job. So that leaves left only why it's working on Windows 7. The solution to that is that you are not guaranteed to intercept the IP packets before reassembly. (For example, that can depend on whether you have a firewall enabled or not.) – David Schwartz Jun 18 '12 at 23:42
  • Forgive me if I'm talking past you. The fact that the XML messages are *not* processed on Windows 7 is completely expected due to the UDP reassembly problem. What is confusing is why the same logic works on Windows XP. Your reply indicates that perhaps the raw socket on the XP system is getting the message *after* it has been reassembled by the system. That would indeed explain the behavior. Is there any documentation that you're aware of that indicates this possibility? – Matt Davis Jun 18 '12 at 23:51
  • If re-assembly is necessary, it will be done. If it's not necessary, it won't. Re-assembly is necessary if, for example, certain firewall rules apply -- you can't run the firewall rule on the fragments. But it's broken on a router (because there's no guarantee all fragments will take the same path). – David Schwartz Jun 18 '12 at 23:53
  • Got it. I just confirmed that the firewall is off on both the XP and 7 systems. Is there any other subsystem to check? – Matt Davis Jun 18 '12 at 23:56
  • Routing and remote access, Internet connection sharing, or anything else that inspects or processes packets. – David Schwartz Jun 19 '12 at 00:02