CIS Firewall forces MTU to 1500 bytes, killing Jumbo Frames [M665]

A. THE BUG/ISSUE (Varies from issue to issue)
[ol]- Summary - Give a clear summary in the topic subject, NOT here.

  • Can U reproduce the problem & if so how reliably?:yes, 100%
  • If U can, exact steps to reproduce. If not, exactly what U did & what happened:
    a:Enable Jumbo Frames in NIC, Network Interface Controller, (set MTU > 1500 bytes).
    b:Transfer data between two systems, tracing NIC interface.
    c:Observe that the large frames are not being passed whole. They are fragmented.
    d:Quick test: Open Administrator command prompt and issue (no quotes)“netsh int ip show subinterfaces”. The MTU will be displayed for all NICs including the one just set. If it is not the same as set, then the problem is confirmed.
  • If not obvious, what U expected to happen: Jumbo Frames to pass frames of the specified MTU (plus 14 bytes). In the quick test method, the set MTU will display not 1500.
  • If a software compatibility problem have U tried the conflict FAQ?:N/A
  • Any software except CIS/OS involved? If so - name, & exact version: N/A
  • Any other information, eg your guess at the cause, how U tried to fix it etc:Turning off the FW or CIS does not correct the problem. Removing the FW corrects the problem. It looks like to me it is the FW kernel mode driver. Also, this used to work fine for CIS version 5.12.
    Evidence that it may be possible to solve this issue can be found here.
    [/ol]

B. YOUR SETUP (Likely the same for each issue, so you can copy forward)
[ol]- Exact CIS version & configuration:CIS 6.3.294583.2937 Proactive

  • Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:All default
  • Have U made any other changes to the default config? (egs here.):No
  • Have U updated (without uninstall) from a CIS 5?:No
    [li]if so, have U tried a a clean reinstall - if not please do?:
    [/li]- Have U imported a config from a previous version of CIS:No
    [li]if so, have U tried a standard config - if not please do:
    [/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:W7 x64 SP1, UAC disabled, Administrator, no VM
  • Other security/s’box software a) currently installed b) installed since OS: a) None b) None
    [/ol]

Please see this Help request for more information. Thanks and enjoy, John.

[attachment deleted by admin]

Thank you for your report.

However, could you please note, in your report, any security software which was currently installed on your system, but is now removed.

Also, please attach the diagnostics report, and a process list, to your first post.

Once this is done I will forward this to the devs.

Thank you.

Chiron, I do not understand your questions.

However, could you please note, in your report, any security software which was currently installed on your system, but is now removed.
I said NONE, what more do you want?
Also, please attach the diagnostics report, and a process list, to your first post.
What is a diagnostic report and why is it needed? Same for process list. How much of my privacy will this invade? Did you read my original post in the Help forum I pointed to? This is not a new problem but was reported on version 3. Thanks, John.

I apologize for the confusion. When you said None originally I was not sure whether you meant none installed right now, or none installed right now and no others in the past. I had to clarify this. I have now edited the first post accordingly.

For your information, the diagnostic report will only have information about CIS, how it is functioning, and basic information from the computer. As far as I know it is not personally identifiable. The process list will just be a list of the processes running on your computer.

However, after looking over your other topic in greater detail, I suspect you are correct about this not being required to reproduce the issue you are experiencing. I am thus willing to forward this to the developers without those two attachments. However, note that I may be wrong about those files not being required. Thus, if the devs do request them please be ready to supply them to the developers.

Thank you.

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

Curious I would expect frames to be fragmented not blocked…

mouse1, you are correct. I don’t think I said that the frames were blocked. When part of the communication chain thinks 9000 byte frames are being sent and other parts think 1500 bytes are, then there is a problem. Thanks, John.

My paranoia has subsided somewhat and I took a look at the Diagnostic Report and decided it was OK to post. Unless the .dmp file (in the .zip file) is the Process List, I cannot discover how to see/create it. The online help shows it but for 5.9 and 5.10 not 6.x. Enjoy, John.

[attachment deleted by admin]

Thank you. I have attached the diagnostics report to the first post.

The process list can be created by opening KillSwitch. This can be found by going to the Advanced Tasks section and selecting “Watch Activity”. Then, after opening KillSwitch, left click on the menu item called KillSwitch and select “Save Current View”. This will create a list of all of the running processes, which you can then put in a zip file and attach to a reply to this topic.

Let me know if you have any questions.

Thanks.

OK sorry, missed that, so by ‘not passed’ you mean the data is being passed but in small transmission units not jumbo frames.

This could be the cause of other CIS performance including latency problems on systems that have non 1500 MTUs but not jumbo frames as standard of course… interesting.

Yes, Mouse1. The frames are fragmented and not Jumbo. I call Jumbo any MTU greater than 1500 bytes. My NICs permit MTU settings of 1500-9000 bytes. An interesting aside: in my about a month, off and on, investigation of this problem I used the Net shell command to set the MTU when CIS FW blocked Windows from seeing the setting in the Device Manager. Then when I did a ping with -f switch (sets the Don’t Fragment (DF) bit) then the frames were fragmented (or simply truncated) somewhere down the road and I did not get a message on the ping command. Timeouts resulted. Here is an example of the case of some of the path knew about the 9000 byte MTU and others saw 1500 byte. I started this investigation to verify that some new router code (firmware) that was supposed to support Jumbo Frames really did. I simply concluded that it did not when I only saw 1514 bytes being passed via Wireshark trace. I suspect that some CIS users have set Jumbo Frames (large MTUs) and assume it is working when only 1500 byte frames are being passed. I did not do a serious speed measurement but I it appears that Jumbos on my minimal home network do improve the speed at least 10%, to about 770Mbps.
I just ran a quick experiment on my LT by opening Properties of the NIC and removing the check on “Comodo Internet Security Firewall Driver” (understand this kills the CIS FW). Now I can set the MTU in device manager and see it with the Net Shell command. Another quick test. Enjoy, John.

Oh please please please remove that ugly bug :‘( :’( :cry:

My environment is the following…

Windows 7 / 64 Bit transfers data to an QNAP- NAS with a cat 6 gigabit network … I use filezilla as a simple ftp client to read / write big files from / to the NAS.

MTU: 9000 at both sides, enable Firewall driver at the NIC : 3-4 MB/sec >:-D >:-D
MTU: 1500 at both sides , enable Firewall driver at the NIC 40-50 MB/Sec ??? ???
MTU: 9000 at both sides, disable Firewall driver at the NIC : 90-110 MB/sec :o

Setting the Firewall to disable but still with the firewall drive enable at the NIC … no change in speed.

tomscher, thanks much for the verification! Enjoy, John.

Another interesting example: I was at a friend’s recently where we ran some Jumbo Frames experiments. The systems we were using ran CIS version 5.12… and JFs worked just fine. Enjoy, John.

Thanks for checking this. I’ve updated the tracker explaining that it used to work fine for CIS version 5.12.

This was tested on 7.0.308911.4080 Beta and still fails. Enjoy, John.

I’m sorry, but I have received information from the devs that this issue cannot be fixed. Apparently, this seems to be a Microsoft Filter limitation. The current filtering architecture limits MTU to 1514, and thus the jumbo frames cannot work.

Thus, although this is not fixed I will now move this to Resolved. I’m sorry that this could not be fixed.

Thank you.

Thanks, Chiron but this makes no sense at all! It worked in CIS 5.xxx. What has changed in Windows since then? Enjoy, John.

I will inquire about this. However, for the time being this post will have to stay in Resolved. If I do not respond within 2 weeks please feel free to send me a PM inquiring about the state of this issue.

Thank you.

Okay, now I understand this situation. For V5 of CIS, CIS was using its own filtering mechanism. However, for multiple reasons, for V6 and up it is now using Microsoft for parts of this process. Thus, this is a Microsoft issue which was not present in V5 because the way CIS filters has changed between versions. I hope that makes sense. If not please feel free to ask for clarification.

Thank you.