IP fragmentation question


I’ve recently downloaded Comodo Personal Firewall BETA, hoping that it’d help me getting one of the games run online over Hamachi. Although I haven’t had any more success than with v2.2.0.11, I’m glad to see that the logging is being improved, as it helped me identify the problem I’m having.

The details:

After looking at the logs in the BETA version, it’s obvious that some packets incoming from my peer’s Hamachi IP address are being dropped with either of the following two reasons:

  1. Reason: Fragmented IP packets are not allowed
  2. Reason: UDP packet length and the size on the wire(xxxx bytes) do not match

Ok, the first one I can solve by disabling “Block fragmented IP datagrams” on the Security/Advanced tab, but I still keep losing packets with incorrect UDP packet lengths.

I did some analysis on the packets with The Ethereal Network Analyzer.
For example here is some info on one of the fragmented UDP packets that CPF/Ethereal reports:


Date/Time :2006-08-09 16:19:32
Severity :High
Reporter :Network Monitor
Description: Blocked by Protocol Analysis (Fake or Malformed UDP Packet)
Direction: UDP Incoming
Source: (My Hamachi IP:someport)
Remote: (Peer’s Hamachi IP:someotherport)
Reason: UDP packet length and the size on the wire(5901 bytes) do not match


Packet #30:
Total Length: 1404
Flags: 0x02 (More Fragments)
Fragment offset: 0
Data (1384 bytes)

Packet #31:
Total Length: 1404
Flags: 0x02 (More Fragments)
Fragment offset: 1384
Data (1384 bytes)

Packet #32:
Total Length: 1404
Flags: 0x02 (More Fragments)
Fragment offset: 2768
Data (1384 bytes)

Packet #35:
Total Length: 1404
Flags: 0x02 (More Fragments)
Fragment offset: 4152
Data (1384 bytes)

Packet #36:
Total Length: 385
Flags: 0x00
Fragment offset: 5536
[IP Fragments (5901 bytes): #30(1384), #31(1384), #32(1384), #35(1384), #36(365)]
User Datagram Protocol
Length: 5901 (bogus, should be 365)
Data (5893 bytes)

As you can see, Ethereal also reports that the length of the last fragment is incorrect. It seems that it contains the sum of all the UDP data transmitted in the fragments, instead of the length of the data in the last fragment. Is this normal behavior for fragmented packets, or is this a problem related to Hamachi, the game, or something else? Is there any way to let those “Fake or Malformed” UDP packets through other than disabling the Network Monitor? (Which is the only way I could get the game work so far… even if the packets are malformed, it seems to cause no problems in the game.)

Thanks in advance for any help!


The upcoming beta release will have option to skip protocol analysis so that such fake packets upon users choice will be allowed.

Such packets do not harm applications but may cause harm to your TCP/IP stack by causing DOS/DDOS attacks.


First of all, thanks for the quick reply. However, doing some more analysis, I am getting more certain that the CPF Protocol Analysis (along with Ethereal’s analysis… unlikely, I know) actually gives false information. I have now manually analyzed the fragments (i.e. the hex dump of the packets), and as the log also states, the “size on the wire”, that is, the total length of all the UDP data carried in the fragments is exactly 5901 bytes. This is the same value as I can read in the UDP header… 5901 bytes. So why does the log say that the “UDP packet length and the size on the wire(5901 bytes) do not match”?

Ethereal states that the UDP length should be 365 bytes instead of 5901 bytes. It’s obvious that it believes that the length of the UDP packet is equal to the size of the data carried by the encapsulating IP packet, which is incorrect, since the UDP packet spans across 5 different packets (fragments), and its total length is 5901 bytes, as correctly stated in the UDP packer header found in the first fragment (and only in the first fragment, subsequent fragments have no UDP header either, so I bet they’re just the continuation of the UDP data). Isn’t it possible that CPF also makes a similiar (possibly false) assumption? It would be nice to see in the log what CPF thinks is the correct UDP length then, so I could prove my theory…

As you can see I’m no networking expert, I base my “networking knowledge” mainly on the wikipedia articles, but common sense also dictates that Hamachi wouldn’t send me corrupted packets… someone prove that I’m wrong, please.

CPF makes the same assumption as in a personal computer, such a traffic is unusual(this would not be a fair assumption in a perimeter firewall).
It is one or many of the routers in your path which cause this fragmentation. I doubt the remote end will initiate such a traffic.
Fragmented UDP headers carry the same size filed as their reassembled versions. Thats why CPF reports header and wire size mismatch. There is no such thing as headerless fragmented IP datagram. Transport header(In this case UDP) must always be included and correctly initialized. No firewall can accept such a packet and risk passing it. If it does, then the PC will be highly vulnerable to all sorts of DOS attacks.

But when you allow fragmented IP packets, CPF should not block those packets unless headerless. It still blocks although you disabled the fragmentation check. This issue has been reported before and fixed in the upcoming beta release.

Good luck,

Are you saying that all the 5 fragments of this user datagram should contain an UDP header? Looking at the packets this way, those headers would be as follows:

IPv4 packet #1 (contains 1384 bytes of UDP data, More Fragments flag set)
Source Port: 49172
Destination Port: 49152
Length: 5901
Checksum: 55216

IPv4 packet #2 (contains 1384 bytes of UDP data, More Fragments flag set)
Source Port: 42808
Destination Port: 56144
Length: 10877
Checksum: 21237

IPv4 packet #3 (contains 1384 bytes of UDP data, More Fragments flag set)
Source Port: 33735
Destination Port: 35817
Length: 49296
Checksum: 52262

IPv4 packet #4 (contains 1384 bytes of UDP data, More Fragments flag set)
Source Port: 60124
Destination Port: 38051
Length: 11210
Checksum: 55246

IPv4 packet #5 (contains 365 bytes of UDP data, More Fragments flag not set but Fragment offset is correct)
Source Port: 8749
Destination Port: 27010
Length: 10222
Checksum: 44082

But only the first packet contains the correct UDP header. (The source and destination ports match the one reported in the CPF log and the length matches the total length of the UDP data in all the 5 packets [also the “size on the wire” in the CPF log].) The other 4 packets clearly don’t have an UDP header. The ports and the lengths of them are all incorrect and I bet the checksum too, although I didn’t check that. There would be no space for those extra headers either, since then the total user datagram length would be 32 bytes less than 5901, which is currently the sum of all the carried data (1384+1384+1384+1384+365 = 5901). So as far as I can tell, everything is fine with these packets the way they are.

If this is not what you meant, then my apologies, I probably misunderstood something in what you wrote. Anyways, I guess I’m being a pain in the @ss with this by now… I’ll just wait for the next BETA release and see if it really fixes the issue or not. I’ll report the results after that.

Thanks again for all the help!

Yes with the next beta, some issues in the protocol analysis logic have been fixed. CPF should not be blocking those packets if you allow fragmented IP packets.