Outline · Standard · [ Linear+ ] ISP Dynamic P2P Port Blocking, Requested workaround for hostile ISPs

[PinBalWyz]

eMulePlus died for your sins. My ISP won't even admit to which ports they block but I discovered what I describe below and request the following feature in new eMulePlus development:

After months of trouble free eMulePlus client use, I found myself with a low user ID despite having unblocked ports 35623 through 35633 on my Linksys router and configuring my eMulePlus client to reflect as much. Still, after brief periods of high user ID, I found myself consigned to low user ID and messages on my eMulePlus client that the port I'd selected/configured couldn't be reached. I tested my ISP related suspicions on a friend's box from a different outside network and found that the ports I'd opened on my Linksys router were 'filtered' when I wasn't using them with eMulePlus, but once I selected and actually began using one for my eMulePlus client traffic, it returned a 'closed' response to my portscanning program, nmap.
I concluded that my ISP is hostile to P2P traffic and tracks such useage, blocking the whatever high port number I chose to use but releasing those I quit using, assigning them whatever value returns 'filtered' instead of 'closed' when scanned.

Therefore, I request eMulePlus developers not only 'widen' the ports eMulePlus uses (perhaps utilizing multiple random port technology) but ALSO impliment a scheme where eMulePlus client users can configure the software to 'block' or 'screen' their eMulePlus ports from being scanned by nefarious ISPs via selecting a range of IP addresses (especially the hostile ISP's) from being able to scan the client machine's useage of these ports (except, of course, the IP address the client machine is currently using for eMulePlus purposes).

In other words, can a filtering mechanism be implimented wherein those seeking to scan a machine's ports for evidence of P2P useage can be excluded from doing so based on the user's parameters? It seems to me that if the hostile ISP simply engaged in static port blocking, my scheme wouldn't work, but the fact that dynamic P2P port blocking appears to be taking place indicates to me some type of testing/scanning of the ports in question for 'evidence' of P2P useage must be occuring.

My present workaround was to pick port 8000 as my selected eMulePlus client configuration port. That's normally the alternate http port. Thus I'm hoping that my ISP will leave that one alone since it often is used for web browser purposes.

Anyone have any constructive thoughts on this? I'd appreciate some feedback and the developers' notions of the feasability of my request.

Thanks.

"Darkness, darkness.....be my pillow!"

This post has been edited by PinBalWyz: Mar 27 2007, 08:14

[LUCA TONI]

in the next version 1.2c emule plus will have the protocol obfuscation and it will resolve your problem