Mod edit: Please help this guy if possible. From the trace this does not look like a bug.
A. THE BUG/ISSUE: Windows Live Messenger Remote Assistance has never worked with Comodo Firewall
- What you did:Tried to use Windows Live Messenger Remote Assistance feature
- What actually happened or you actually saw: I accepted a request for remote assistance (to help the other user). Request was accepted, I received the Password Prompt for the session, and entered it as provided by the user (it was 123abc). The session never actually began. This issue has been ongoing for a while now and I believe its never worked with Comodo Firewall.
- What you expected to happen or see: It should have launched a window for the Remote Assistance session, showing me the users screen.
- How you tried to fix it & what happened:By disabling the Firewall AND rebooting I am able to make the Remote Assistance session. (Please note this uses UPnP)
- If a software compatibility problem have you tried the compatibility fixes (link in format)?:
- Details & exact version of any software (execpt CIS) involved (with download link unless malware): All current versions of Windows Live Messenger released in the last two years.
- Whether you can make the problem happen again, and if so precise steps to make it happen:
- Log into a Windows 7 x64 computer.
- Open Windows Live Messenger and log in.
- Have another user log into WLM from another PC (without Comodo) on a different network only reachable over the internet (each user behind different modern/current home router/firewalls). (They must be friends in WLM, so do that if needed)
- Have the other user submit a Remote Assistance request (for you to help them).
- Accept the RA request.
- Have the user enter a password for the session when prompted.
- Have the user provide you the password (via any method possible).
- When prompted on your computer, enter the password given.
- The session should start here, but never appears. There is no indication the local computer is attempting anything at this point.
- Any other information (eg your guess regarding the cause, with reasons):
UPnP or Windows core system network issue. Note that a reboot is mandatory to resolve the issue after Comodo changes are made. It will not work unless a reboot occurs. There are no firewall blocks logged in Comodo or elsewhere. There are no Defense+ blocks logged. UPnP behaves fine. Session works when no Comodo Firewall is involved. This has been going on for 2 years and I’m finally submitting this bug because its ridiculous. I will happily friend someone on WLM to troubleshoot this from the Comodo side.
B. FILES APPENDED. (Please zip unless screenshots).:
- Screenshots of the Defense plus Active Processes List (Required for all issues):
- Screenshots illustrating the bug: irrelevant
- Screenshots of related CIS event logs:
- A CIS config report or file:
- Crash or freeze dump file:
- Screenshot of More~About page. Can be used instead of typed product and AV database version:
C. YOUR SETUP: Windows 7 x64, fully patched.
- CIS version, AV database version & configuration: CIS 5.8.213334.2131
- a) Have you updated (without uninstall) from a previous version of CIS:No
b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:Yes
- a) Have you imported a config from a previous version of CIS:No
b) if so, have U tried a standard config (without losing settings - if not please do)?:Yes
- Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.):
- Defense+, Sandbox, Firewall & AV security levels:Custom, Off, Custom, Not Installed
- OS version, service pack, number of bits, UAC setting, & account type:win7 x64 SP1, 64bit, UAC Always notify, User
- Other security and utility software currently installed:Avira Free AV
- Other security software previously installed at any time since Windows was last installed:None
- Virtual machine used (Please do NOT use Virtual box)[color=blue]:None