Low ID with Emule and Comodo 4

Low ID and Emule!
Frustrating indeed!
Yes I’ve read the very extensive tutorial here:
https://forums.comodo.com/guides-cis/firewall-tutorial-for-emule-with-comodo-internet-security-t14735.0.html
and I’ve read the informative post here:
https://forums.comodo.com/firewall-help-cis/emule-gives-lowid-even-following-the-tutorial-with-cis4-not-with-cis3-t53677.0.html
and yet I can’t seem to get emule working properly…
I’ve changed the ports on emule (both for UDP and TCP) and changed the corresponding rule on Comodo but the results stayed the same…
I’m running win7 (with the built-in FW turned off).
My current configuration is:
Emule TCP port: 15066
Emule UDP port:15646
Comodo Emule policy (moved up to the top of the application policies):
TCP IN - Allow any source and any destination ports (yes I know it’s inscure but even THAT doesn’t work yet)
UDP IN - Allow any source and the destination port is 15646.
TCP and UDP out - allow any source and any destination ports.
ICMP OUT - any source and any destination ports ICMP echo Request
Rule for HTTP requests - same as it was detailed in the tutorial (there were no problems in that section)
I’ve even removed the “block all unmatching requests” emule rule, and there’s no “all applictions” rule that does the same.
Also, the Global rule that was mentioned in other posts:
“Block and Log IP In From IP Any to IP Any Where Protocol is Any” rule to drop incoming connections."
was not present in my case…

I’m attaching the event log to this message.

I’d greatly appreciate any input!

Cheers!

p.s:
after making some changes on the FW and restarted emule, the Comodo asked about the connection again, and I asked him to use “Emule” policy, still I got the low ID blockage…something is still wrong with my settings! (and it’s not even secured properly, I only used that low security setting for testing…)
P.S2:
sometimes I start from Low ID, then later it becomes high id for a short while and later I’d get a message like:
Warning eDonkeyServer No2 (212.63.206.35:4242) - No answer from your 15066 port. Please review your network config.
looking at the event log (attached) I couldn’t find any reference for the apparently blocked 15066 port…

Help!

[attachment deleted by admin]

Can you show you a screenshot of your Global Rules?

Thanks for the quick reply Eric,
I’m attaching the screen shot.

[attachment deleted by admin]

This time I did find an event that shows how my TCP port is being blocked.
I’m attaching a screenshot.
It says the application is “Windows Operating System”, does that mean it’s not the Comodo that’s blocking?

[attachment deleted by admin]

When CIS reports WOS is blocking it means that no program is listening and it gets blocked.

Can you take a look in the Application Rules list and see if the e Mule rule is anywhere under the All Application rule. When it is move it to a a place somewhere the All Applications rule. WHen a program rule is somewhere under it is subordinate to the rule set by the All Applications rule (changing of the e Mule rule does not work then).

With your Global Rules settings you should get an alert about incoming traffic

You mean, no program tried to use it for a while and it got blocked?
how come?
or did I misunderstood your intention?

I’m attaching a screenshot of my Emule rules under the applications tab, the emule rule is right at the top of the list, so it shouldn’t be affected from the other rules…
(I wonder why is it greyed out though?)

also, on the event log, I won’t see any event related to Emule, besides UDP traffic directed to other ports than the one I specified.
(no TCP blocking, besides the WOS one I pointed above…)

[attachment deleted by admin]

When you start e Mule do you get alerts that traffic wants to come in on the TCP and UDP port?

Because there is no program listening it will get blocked. After you signed out from the E Donkey (or Torrent or any other p2p network) the other computers don’t know. So, they will be sending requests until all of them know you are not online anymore. That’s why you see incoming traffic being blocked at the e Mule ports hours after you closed down e Mule.

I'm attaching a screenshot of my Emule rules under the applications tab, the emule rule is right at the top of the list, so it shouldn't be affected from the other rules.. (I wonder why is it greyed out though?)
That's because you are using a predefined policy.
also, on the event log, I won't see any event related to Emule, besides UDP traffic directed to other ports than the one I specified. (no TCP blocking, besides the WOS one I pointed above..)
As for the other traffic. I guess that is regular background noise. Do these port numbers mean anything to you? Port 6496 is not a "known port" and can be used by any program. The port 63884 is part of the socalled Dynamic/Private port that gets used by many programs; think p2p clients, Instant Messenger clients...etc.... Read this link for a little reference: http://www.speedguide.net/port.php?port=6496&print=friendly .

Thanks again for your reply Erik.

When I look at the eventlog I find that the only blocked event related to emule is when UDP
Traffic is being directed to other ports than the one I specified. (my emule UDP port is 15646)
I’m attaching a screenshot. (btw, you guys missed an “L” on the heading of that window(:slight_smile:

I see a few instances of the example above. The destination port (mine) sometime changes, but the source port (port 32951) doesn’t.

only if I delete the rule from “Network Security Policy”, then when I start emule again, it will indeed ask me (properly) for both the UDP and the TCP traffic. (I’ll also see the ask event on the log).

[attachment deleted by admin]

I am starting to wonder whether your router’s ports have been opened. Can you look into that?

When you don’t know how to open ports on your router you can find tutorials for that at http://portforward.com.

Hey Erik, thanks for your reply again.

I don’t use a router, so the router ports are irrelevant(:
my question - looking at the screen shot I attached on my last post here, isn’t that the normal FW behavior?
After-all, it blocked UDP traffic that was directed to an unspecified port…

Indeed. I could have known you are not behind a router as the desination address is a public IP address… -10 points for Gryffindor here…

my question - looking at the screen shot I attached on my last post here, isn't that the normal FW behavior? After-all, it blocked UDP traffic that was directed to an unspecified port..
That's what we want.

When you reply and tell it to remember your answer to allow do you get HiGH ID and a proper connection to the KAD network?

To Erik and all who may be reading:
Looks like the problem is solved!

I’ve been connected for the last 18 hours and only had 3 very short disconnection during that time.
I don’t think it was the FW settings that were stopping me from getting the high ID yesterday.
I think it was messing with the settings too much, changing ports, logging on and off (this activity alone can get you blocked by the servers…)

so to sum things up, the only changes I’ve made were :

  1. Change the UDP/TCP ports to values between the 25000 and 39999 (I’ve read elsewhere that this is the best range) .
  2. Define edonkeyserver No 2 as high priority and static.
  3. leave emule alone(:

I thank you all for your time and effort, I’m now another happy user(:

P.S:
I did learn more about how this FW works, so it’s all good(:

Not all servers may give a High ID when they should. You may be interested in How To Get A Reliable Server List & A Good IPFIlter from the official e Mule support fourms. This is to be sure you connect to proper servers and block IP’s with potentially questionable motives.

Yes I know all about servers reliability, I’m using:
http://www.peerates.net/servers.php
as my only server list

and I use:

http://blocklistpro.com/download-center/start-download/p2p-ip-filters/1633-nipfilter.dat.gz.html

as my Ipfilter.
would you recommend using the ipfilter manager as well?

ie:

http://blocklistpro.com/the-blocklist-manager-2.7.7.html

You’ve been great help on this.Thanks again Erik.