A. Nonymous
2014-01-06 03:19:33 UTC
As of today I can no longer connect to eMule Security No. 1
(91.200.42.46:1176). SYN packet produces no response for several seconds
and an eventual RST response (reported by typical application software as
"connection refused by host"), as if I've either contacted the wrong
IP:port or run afoul of an IP ban.
It's not the wrong IP:port -- http://www.emule-security.org/serverlist/
lists it and even claims it has 18,646 connected users at the moment (may
have changed by the time you read this), and they ought to know if their
own server is still a going concern.
It shouldn't be an IP ban either. I downloaded the filter they are offering
for end-users to use from http://upd.emule-security.org/ipfilter.zip and
opened the file inside in Notepad. My IP was not in the list, nor was a
range containing it. If their servers implement bans of the same IPs, then
that's not the cause either. And then there's the minor little matter of my
not having done anything wrong to provoke such a ban, and the fact that I
tried to connect from three IPs with the same result, so if there is a ban
it's a ban of my entire ISP and not a temporary ban of one IP. I'd hope
that it would take a high bar of severe and repeated abuse for them to
server-ban a whole DHCP pool rather than temp-ban a single malefactor until
he gave up and logged off.
ISP throttling also seems unlikely. First of all, most traffic-shaping ISPs
just drop packets or do other dirty tricks to slow or block P2P, if they
attack P2P at all; and most that do attack P2P focus on Bittorrent. Second,
traffic shaping is climate, not weather, unlike short-term IP bans, and
while it's relatively likely for today to be a snow day, it's quite
unlikely for today to be the first day of a new Ice Age. Similarly it's
unlikely that today happens to be the day my ISP suddenly goes all Dark
Side on me.
In fact, the only censorship regime I know of that specifically uses
spoofed RST packets to simulate the remote host hanging up on the customer
is the Great Firewall of China, which should not lie between me and eMule
Security No. 1 and last I checked did not interdict traffic that neither
originated nor terminated inside of China anyway.
A further argument against ISP throttling is that it would be likely to be
based on protocol, rather than narrowly targeted at connections to one ed2K
server and not to others, and yet I *can* connect to TV Underground No. 1,
which fact also argues forcefully against the problem being wonky
networking equipment at my end, or my ed2K client having gotten into a
wonky internal state of some kind. (And on top of that rebooting said
equipment did not work, and neither did restarting the client software.)
This brings things back around to some sort of mistaken IP ban at the
server level as the likely culprit, especially since I cannot seem to
connect to any other Emule Security server either, whereas I can connect to
TV Underground.
How can I report having been blocked in error and get the block lifted? The
eMule Security web site does not offer any obvious way to do so safely. In
particular there's no unban-request form or similar (either for their
servers *or* for their published filter list), and in fact the only
apparent contact method is a Contact Us form that demands a working email
address. Understandably, I'd prefer to limit my exposure of my identifying
information to just revealing the IP range that needs unbanning.
And, is there a fifth possibility, something else than server down, IP ban,
wonky hardware/software at my end, or ISP throttling, that could explain
these symptoms? Which are, in capsule summary, a selective inability to
connect to any eMule Security affiliated ed2K server that does not appear
to affect ability to connect to any other ed2K servers (let alone to use
HTTP, NNTP, and so forth) from the same machine.
(91.200.42.46:1176). SYN packet produces no response for several seconds
and an eventual RST response (reported by typical application software as
"connection refused by host"), as if I've either contacted the wrong
IP:port or run afoul of an IP ban.
It's not the wrong IP:port -- http://www.emule-security.org/serverlist/
lists it and even claims it has 18,646 connected users at the moment (may
have changed by the time you read this), and they ought to know if their
own server is still a going concern.
It shouldn't be an IP ban either. I downloaded the filter they are offering
for end-users to use from http://upd.emule-security.org/ipfilter.zip and
opened the file inside in Notepad. My IP was not in the list, nor was a
range containing it. If their servers implement bans of the same IPs, then
that's not the cause either. And then there's the minor little matter of my
not having done anything wrong to provoke such a ban, and the fact that I
tried to connect from three IPs with the same result, so if there is a ban
it's a ban of my entire ISP and not a temporary ban of one IP. I'd hope
that it would take a high bar of severe and repeated abuse for them to
server-ban a whole DHCP pool rather than temp-ban a single malefactor until
he gave up and logged off.
ISP throttling also seems unlikely. First of all, most traffic-shaping ISPs
just drop packets or do other dirty tricks to slow or block P2P, if they
attack P2P at all; and most that do attack P2P focus on Bittorrent. Second,
traffic shaping is climate, not weather, unlike short-term IP bans, and
while it's relatively likely for today to be a snow day, it's quite
unlikely for today to be the first day of a new Ice Age. Similarly it's
unlikely that today happens to be the day my ISP suddenly goes all Dark
Side on me.
In fact, the only censorship regime I know of that specifically uses
spoofed RST packets to simulate the remote host hanging up on the customer
is the Great Firewall of China, which should not lie between me and eMule
Security No. 1 and last I checked did not interdict traffic that neither
originated nor terminated inside of China anyway.
A further argument against ISP throttling is that it would be likely to be
based on protocol, rather than narrowly targeted at connections to one ed2K
server and not to others, and yet I *can* connect to TV Underground No. 1,
which fact also argues forcefully against the problem being wonky
networking equipment at my end, or my ed2K client having gotten into a
wonky internal state of some kind. (And on top of that rebooting said
equipment did not work, and neither did restarting the client software.)
This brings things back around to some sort of mistaken IP ban at the
server level as the likely culprit, especially since I cannot seem to
connect to any other Emule Security server either, whereas I can connect to
TV Underground.
How can I report having been blocked in error and get the block lifted? The
eMule Security web site does not offer any obvious way to do so safely. In
particular there's no unban-request form or similar (either for their
servers *or* for their published filter list), and in fact the only
apparent contact method is a Contact Us form that demands a working email
address. Understandably, I'd prefer to limit my exposure of my identifying
information to just revealing the IP range that needs unbanning.
And, is there a fifth possibility, something else than server down, IP ban,
wonky hardware/software at my end, or ISP throttling, that could explain
these symptoms? Which are, in capsule summary, a selective inability to
connect to any eMule Security affiliated ed2K server that does not appear
to affect ability to connect to any other ed2K servers (let alone to use
HTTP, NNTP, and so forth) from the same machine.