Blocked MySQL connection

Comodo Internet Security - CIS Defense+ / Sandbox Help - CIS
1

Hi,
I have an application that connects to a MySQL server through ODBC driver 5.1.
The server resides on a Windows Server 2008 R2 box.
The application fails to connect, with error “Can’t create TCP/IP socket (10022)”.
The problem disappears when I uninstall COMODO Antivirus Free.

I have this error on Windows 7 with 5.5 and 5.8 COMODO antivirus versions, and only when the application executable resides in a network share. The error doesn’t show up on Windows XP, whatever the version is, on Windows 7 with older antivirus versions, for example 5.0, and when the application resides on a local drive.
D+ and sandbox are disabled, and the log doesn’t show any event.
The connection to the MySQL server is working fine because I can connect to it through telnet.

I want to clarify that I’m speaking about COMODO antivirus only, without firewall.

Is there something to change or disable to solve the issue?
Thanks,
Riccardo

2

Hello.
I have the exact same problem. I know for sure that is comodo’s fault.
However if you run your application from a network location, I suggest to change your executable name in something like this: program_1.exe.
I have noticed that including the _ (underscore) somere in the middle in the file name get rid of the problem.
I know it sounds stupid, but it worked for me.
Let me know if it worked for you too.

3

I changed the file name according to your suggestion, adding “_1” between the original name and the “.exe” extension, but it didn’t work. I tried to add the undescore at the start or at the end of the name, without other chars, but it didn’t work too.

Anyway, thanks for your help attempt.

4

Hello again.
I know now that it was not the _ (underscore sign) but it was the length of the file name.
Please try a file name larger than 8 characters (something like 123456789.exe)
Waiting for your response.
Best regards.

5

Thanks again for your help.
I tried different things related to your suggestion but none of these works:

  • File name longer than 8 chars.
  • File name ending with “~1” shorter than 8 chars (“~1” included).
  • File name as above 8 chars long.
  • File name as above longer than 8 chars.
    With “file name” I mean the name without the extension, that was of course always “.exe”.
6

Sorry to hear that. I give up!
In my case, network filenames longer than 8 chars solved the problem.

7

I found the solution.
Every component of the path has to be longer than 8 chars.
In my case the path was “X:\Folder\Executable” and the “Folder” component was shorter.
Thanks to gavroche for pointing me in the right direction.

I think it should be signaled as bug, but I don’t know exactly as to do it. It’s not a result of a specific actions sequence but it’s a persistent behaviour in every situation and with every configuration (for example it shows up even with D+ enabled). Maybe a moderator can help me…

8

Please edit your first post in this topic to make an issue report in the bug forum in standard format as described here.

Then devs will have the info they need to fix it.

Many thanks

Mouse