Very slow Netbios Performance

Help for v3
1

Hi,
my data:

Notebook:
Dell Latitude D520

OS:
WinXP SP3 fresh install

Installed Software:
Dell Drivers
Broadcom Management Program
GT HSDPA Driver (UMTS)
Intel Proset Wireless Software
Netscreen-Remote (VPN Client from Juniper)
Quick Set from Dell

Comodo 3.0.25.378 without defense+ and without leak protection

My situation:
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.

Edit: Uploads added

[attachment deleted by admin]

2

Bump

3

Traffic dumps via upload added

4

Bump

5

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.

6

Hi grue155,
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.

[attachment deleted by admin]

7

Next update:
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

Hope comodo will solve that bug/issue.

8

Hello Netbez,

Turn off “Blocked Fragmented IP Datagrams” in Firewall>>Attack Detection Settings>>Miscellaneous – this worked for me.

9

Thank you. I had forgotten about the blocked datagram check. In this context, it makes sense to have that block turned off.

10

Hi,
sorry but this didn’t work for me with Comodo 3.
The setting “Blocked Fragmented IP Datagrams” only works with Comodo 2.4.

If I disable the Comodo Firewall the problem should have gone. But it still persists. :cry:

11

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.

12

As you can see at the attached traffic logs. The requests are totally different.
With Comodo there are 4 packets to get the same Info

Without Comodo.
210.098598 10.199.249.152 → 10.199.0.12 SMB Trans2 Request, QUERY_PATH_INFO, Query File Basic Info, Path:
210.098768 10.199.0.12 → 10.199.249.152 SMB Trans2 Response, QUERY_PATH_INFO

With Comodo:
795.657795 10.199.249.154 → 10.199.0.12 SMB NT Create AndX Request, Path:
795.657996 10.199.0.12 → 10.199.249.154 SMB NT Create AndX Response, FID: 0x800c
795.807338 10.199.249.154 → 10.199.0.12 SMB Close Request, FID: 0x800c
795.807479 10.199.0.12 → 10.199.249.154 SMB Close Response

13

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.

The basic test is described at http://help.expedient.net/broadband/mtu_ping_test.shtml, and a tool to more easily tweak the Windows settings is available at http://www.dslreports.com/drtcp

It’d help me to understand your VPN latency if you posted the results of the MTU ping test.

14

Hi grue155,
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.

15

I’m running short of ideas here. Let me query the other moderators to see if anybody has suggestions.

16

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.