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?

7
  • 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? Jun 18, 2012 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." Jun 18, 2012 at 20:31
  • @David Schwartz, break what rules?
    – Matt Davis
    Jun 18, 2012 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, 2012 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. Jun 18, 2012 at 23:22

1 Answer 1

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.

6
  • 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, 2012 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.) Jun 18, 2012 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, 2012 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). Jun 18, 2012 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, 2012 at 23:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .