When I try to run windows ping.exe with the buffer size (-l option in ping.exe) set to 1017 or greater the request times out. However, if I Turn Off the “Network Control Rules”, I can ping with a buffer of 1017 or greater (until expected fragmentation sets in). I am using the default settings Network Control Rules settings (I just installed Comodo Personal Firewall for the first time today).
I even tried making Network Control Rules that would allow all ICMP traffic in and out (and put the rule at the top) as a test, but the problem still happened unless I turned off the Network Control Rules completely.
I do not know if this is a symptom of anything that could really cause noticeable problems elsewhere, but I figured I point it out just in case. Is this really just benign or is it indicative of a larger problem than may surface elsewhere?
I am using Windows XP SP2. Here are the examples :
Example with “Network Control Rules” Turned On and buffer = 1017
Great detective work, but what on earth made you think to check the buffer size? What was your reasoning - prior problems with buffers on another firewall? And how did you arrive at the figure of 1017? Please don’t say you went “-l 1”, “-l 2”, “-l 3” etc. LOL
Loved the detail you put in your posting. Good job!
I checked the buffer sizes with ping.exe because I was using TCP Optimizer (SpeedGuide.net - TCP Optimizer) and was running the section that checks for the largest MTU you can use. That part of the program just runs pings with different sizes. When I ran it I saw the following:
Pinging [184.108.40.206] with 40 bytes ->bytes=40 time=28ms TTL=54
Pinging [220.127.116.11] with 750 bytes ->bytes=750 time=28ms TTL=54
Pinging [18.104.22.168] with 1125 bytes ->Request Timed Out
Ping terminated by user
So from there I decided to try ping.exe manually (tried 1000, then 1100, then 1050, then 1025…) until I narrowed down which buffer size was the minimum needed to hit the problem. I was pretty sure this had worked before installing Comodo PF, so the I tried turning off different parts of the PF until I found the one that was causing the issue (Network Control Rules).
Any thoughts on why this happening or if it’s really a problem?
…I am now in the process of trying to ping every computer that’s connected to the internet to see if any of those fail due to the PF.
I am glad you brought this topic into attention. Although we did not provide a user interface for it yet, CPF has a “Protocol Analysis” engine to reduce the number of suspicious, possibly deadly, network packets to be sent/received.
An ICMP packet having size more than 1024(1016 data + 8 bytes ICMP v4 header i.e. 1017 is above the acceptable threashold) bytes is a suspicious, for a personal computer, even for a server computer because of many reasons(For example Snort IDS will produce an alert for such a case).
Thats why CPF “Silently” drops them. The future versions of CPF will have an interface for protocol analysis configuration and logs.