Broadcom Management Program
GT HSDPA Driver (UMTS)
Intel Proset Wireless Software
Netscreen-Remote (VPN Client from Juniper)
Quick Set from Dell
Comodo 184.108.40.2068 without defense+ and without leak protection
Netbios traffic is very slow at the moment I have installed the comodo firewall.
What I do:
I do a connect to UMTS then I start my VPN Tunnel.
I have connected about 8 network drives which I need for my work.
Now If I open my Windows Explorer I must wait about 36 seconds.
If I do this without Comodo I have to wait about 8 seconds.
If I disable the Comodo Firewall, the services and the drivers I still have the same problem (36 seconds)
Only I if uninstall Comodo the explorer opened in 8 seconds.
I have dumped the traffic.
You can see at the trafficdumps that the traffic with comodo has much more packets than the traffic without comodo. There are about 4 times more packets.
I hope the development can fix this problem or help me to get this problem solved.
Please ask if you need further information.
I’m not sure if I can help or not, but I’ll take a try.
Part of your network description is confusing to me. You have 8 network drives, being accessed thru a VPN? That has some overhead by itself.
Could you run the CFP Config Reporting Script and post the result here. Its available in one of the sticky topics at the top of this forum page. There might be something in the order of the CFP rules that is causing some kind of problem, particular to going thru a VPN.
the configfile is attached.
I know that SMB Traffic itself is not the best but we need it.
I don’t think that it is a configuration issue, because
I think it has something todo how comodo handels the packets.
I did another test with the NCP Client which shows the same behavior. About 24 seconds instead of 8 seconds without comodo. You can try it yourself if you want. NCP Client is shipped with a 30 days test license.
Next I will try with another firewall and post the results.
Result testing without any firewall → 8 seconds.
Result testing with Ashampoo Firewall → 10 seconds.
Result testing with Comodo Firewall 2.4 → 10 seconds
Result testing with Comodo Firewall 3 → 36 seconds
I’ve looked back over your CFP config report, and nothing obvious is staring back at me.
That tells me, the next step is to see what the traffic is itself, using a network monitor. Wireshark is one that is often used, and is fairly straightforward. It’s available at http://www.wireshark.org/ Microsoft also has a monitor Network Monitor v3.1, but it requires the .NET Framework which is a multimeg download.
I’m suspecting the ICMP packets are reporting traffic congestion errors, but to find out means seeing the ICMP traffic, and that takes a network monitor. It could be something in packet sizes in MTU settings, but that takes seeing the packets also.
Unless there is a path info request before each and every file buffer access, I kind of doubt that 2 packets becoming 4 packets for a pathname is going to cause a problem in network latency. It’d take x1000s such, unless there is a really slow link.
But SMB traffic isn’t the ICMP traffic. It’s the ICMP stuff that probably needs to be looked at.
Lacking a packet capture for ICMP, I’m going to suggest checking into the MTU sizing on the VPN.
I have tested the mtu.
It is in both times (with and without comodo) 1272.
If I try a ping larger then this without the parameter -f, the packet will be fragmented also if comodo is installed.
I dont’t think that I have to adjust something at the MTU or VPN.
With Comodo 2.4 and Ashampoo I didn’t have these problems.
I must be something at the Comodo 3 drivers.
Several of the other moderators have looked over this topic, and the consensus is that you’ve got a real live Comodo bug, either in the code itself or in how it is interacting with other applications. In any event, the collective suggestion is to file a bug report in https://forums.comodo.com/bug_reports-b106.0/
I’m sorry that there doesn’t seem to be a better solution for your situation at the moment. We’re kind of stumped.