cygwin problem

hi there!

i have just installed comodo after being a zone alarm user for years. i just couldn’t stand it anymore. it was such a resource hog.

i like comodo so far. it’s light (my boot and log on times have increased dramatically since uninstalling za) the interface and workflow is a bit strange and cumbersome after using ZA. i liked how ZA had zones. the rules window is a bit confusing and annoying usability wise(it doesn’t resize - jacob nielsen would commit sepukku over this) … especially if you get lots of rules

now i have a big problem which might make me find another product (looking at jetico which scored pretty good in the Matousec test)

i do a lot of development and sysadmin work over ssh. i use cygwin and use private/public key authentication instead of passwords. with Comodo Firewall i can’t do that anymore although i added ssh-add.exe, ssh-agent.exe, and ssh.exe to the list of trusted apps and also checked the skip security checks option

here is what happens (this is in bash using cygwin on xp):
$ eval ssh-agent
Agent pid 2120

$ ssh-add.exe .ssh/key1.dsa
Enter passphrase for .ssh/key1.dsa:
Error writing to authentication socket.
Error writing to authentication socket.
Could not add identity: .ssh/key1.dsa

$ ssh-add -l
Error writing to authentication socket.
Error writing to authentication socket.
The agent has no identities.

this only happens when Comodo is on.

any help would be appreciated. let me know if you need any other information that might help debug this… and thanks for developing Comodo


Please doubleclick CPF GUI window Title and post a screenshot of your Network rules and Miscellaneous setting.

Then please export your log, then clear the log and reproduce the issue.
Wait about 30 sec an export the new log edit out relevant privacy info and post it.

If you don’t mind privacy you can backup your CPF settings and post them.

it looks like turning on skip loopback tcp connections did it! ;D
thanks for the indirect tip!

i also added cygwin1.dll to trusted components.

looking forward to version 3!


??? I didn’t think about skip loopback tcp connections. :o
I was more oriented about alerts and nw rules.

When an app act as a server or connects to loopback the application monitor should pop up an alert.
So if alerts are not disabled this should be a bug.

Do you have component monitor set to ON or in Learning Mode?

the component monitor is set to learning mode

and yes it’s the tcp skip option. to confirm i’ve disabled it several times and it doesn’t work with it off

before i found the skip option i cranked the alert level to very high and i looked in the logs… during the ssh operations there was nothing denied and no alert popped up

i thought the ssh programs used unix sockets to communicate with each other. cygwin must emulate the unix sockets with tcp sockets

still i would think that setting an app to be trusted should be enough as a rule

if you think this is a bug let me know and i can provide information on how to replicate this behavior

Yes, this seem a bug to me.

The cygwin1.dll had to be automatically added in trusted components when component monitor is set to learning mode.

Also when the alert frequency is very high and alerts are not disabled an alert pops up almost on every connection including loopback tcp ones (if tcp loopbak is not skipped)

If alerts are disabled and a connection is blocked an entry is written to the log.

Does this happen only with cygwin binaries?

BTW maybe is worth to wait for the beta release on 7th june to check if this issue is resolved by V3.

Yes, at least for Networking cygwin act as a wrapper and a trusted app had to have no problem connecting.


Socket-related calls in Cygwin simply call the functions by the same name in Winsock, Microsoft’s implementation of Berkeley sockets. Only a few changes were needed to match the expected UNIX semantics - one of the most troublesome differences was that Winsock must be initialized before the first socket function is called. As a result, Cygwin has to perform this initialization when appropriate. In order to support sockets across fork calls, child processes initialize Winsock if any inherited file descriptor is a socket.

Unfortunately, implicitly loading DLLs at process startup is usually a slow affair. Because many processes do not use sockets, Cygwin explicitly loads the Winsock DLL the first time it calls the Winsock initialization routine. This single change sped up GNU configure times by thirty percent.

Sure this AM behaviour is strange ???