Please see this thread for the lead up to this:
The OSR Online response to a question about setting the MTU defines a couple of Keys with values (Inspect.inf uses these settings) and references how to use the LWF (Light Weight Filter) “FilterRestart handler” to change the MTU. It looks like to me that this is what the users need to be able to use Jumbo Frames (MTU > 1500 bytes). Please consider it. Thanks and enjoy, John.
I have re-opened this in the tracker for consideration. I will move this bug report back to Format Verified as well.
The devs have not marked this as Fixed in the tracker. However, sometimes bugs are fixed by the release of new versions, but not marked as Fixed in the tracker.
If you are able please check with the newest version (CIS version 8.0.0.4337) and let me know if this is fixed on your computer with that version.
Thank you.
The problem with jumbo frames is not fixed in 8.0.0.4337
Thank you for checking this. I have updated the tracker.
Thanks, Chiron. Sorry I missed your post. Perhaps, in the future, you can PM me. I have not been checking this lately.
Thanks, ASk4Net for testing 8.0.0.4337. I just installed 8.0.0.4344 and tested JFs. They still do not work.
Enjoy, John.
I’ve updated tracker data.
Thank you.
This problem is about a year and a half old. When can we expect to get it resolved? Thanks, John.
Marked as not fixed in version <8.2.0.4508>.
Please wait… Hoping it gets into discussions for a clear status.
I will try to keep you updated.
Thanks.
Thanks, qmarius. Hopefully soon. Enjoy, John.
I just tested jumbo frames on CIS version 8.2.0.4591. The MTU continues to be locked at 1500 bytes. When WILL this be corrected? Thanks, John.
Sorry, John. Nothing new, yet.
I’ve updated tracker data.
Thanks.
Still not corrected in 8.2.0.4674. Is it time to surrender? Enjoy, John.
Resolution did not change. No (official) statement, yet.
I’ve updated tracker data.
Thank you.
Hi John
I am one of the people (albeit just a volunteer) who looked into this for you. At the time I discovered that the MS framework being used by Comodo did not support higher MTUs. Which as observed is strange as the MS firewall does. But that would not be the first time that MS had not revealed a facility to competitors 
However if the above fix applies to the framework Comodo uses, and you can demonstrate it does, we would I guess have some chance of getting this fixed. At the moment I think they see it as a technical impossibility unless they use a different framework
If only the inf file is involved. I guess the procedure might be something like:
But stand by for blue screens (IE backup everything first)
Kind regards
Mike
Unfortunately modifying the inf file is not the only steps need as described in the OSR post witch I will quote here
1. Make sure to mark your LWF as a Modifying and Mandatory filter. If your filter is not Mandatory, then NDIS may bind TCPIP before your filter has a chance to attach and modify the MTU. Do this by setting these values in your INF: [b]HKR, Ndi,FilterType,0x00010001, 2[/b] ; Modifying filter [b]HKR, Ndi,FilterRunType,0x00010001, 1[/b] ; Mandatory filter 2. In your filter's FilterRestart handler, look in RestartParameters->RestartAttributes. This is a linked list of objects - find the object with ObjectID of OID_GEN_MINIPORT_RESTART_ATTRIBUTES. (The current version of NDIS only has a single Object ID in the list, so the sample filter takes the shortcut of assuming the first entry is a miniport restart attributes). 3. Cast the restart attributes to an NDIS_RESTART_GENERAL_ATTRIBUTES. The sample's FilterRestart function illustrates how to do this: http://code.msdn.microsoft.com/NDISLWFSYS-Sample-NDIS-60-42b76875/sourcecode?file Id=42729&pathId=1048232060 . 4. Modify NDIS_RESTART_GENERAL_ATTRIBUTES::MtuSize to your new value. 5. Continue with FilterRestart as normal.and if you take a look at the inf file for inspect driver, you will notice the values needed are already set from step 1. - [b]HKR, Ndi,FilterType,0x00010001,0x00000002[/b] - [b]HKR, Ndi,FilterRunType, 0x00010001,0x00000001[/b]
So steps 2,3,4,5 is what comodo needs to do on their end with the source code.
Information passed on via tracker, and status update, and QA discussion requested.
Thanks much, mouse1 (Mike). I have not been keeping a close watch on this post but am very glad someone (especially someone much more technically qualified than I) has spent time on this. As I read your responses, it is again time to wait and see if the developers will attend to the problem. BTW, what version of .NET does CIS use? I always run the latest (4.6 at this time). Thanks again and enjoy, John.
The MSDN link fails even when the blank is removed - maybe just old.
I have a theory on what the issue maybe. I have a marvell yukon NIC card and in the driver advanced settings i can set jumbo packet to 1514, 4088, or 9014 Bytes, and after choosing say 9014 running netsh command still shows 1500 mtu value. But if I run netsh interface ipv4 set subinterface “Local Area Connection” mtu=9014 store=persistent then the mtu value does change to 9014. Have you tried setting the mtu that way?
Just an update, this has been confirmed now. So maybe they will fix.
I will let Futuretechsee if there is a work around/fix for you, as he has experimented more than I have.
(Thanks FT )