留言板

这里是emulefans.com电骡爱好者Blog的留言板，您可以就任何话题（当然一般来说还是与eMule/eD2k/P2P相关主题，或者本Blog的事务相关的）在这里留言。

查看本站的信息请至关于页面；需要Email联系我们者请直接发送邮件至[email protected]；eMule/eD2k/P2P相关主题文章的投稿也可贴在这里或用Email联系。

50条评论隐藏

#1 asp502010

2013年4月7日周日 08:30 | 回复

@无敌稻草人
迅雷神马的被屏蔽。

使用XTreme+sdc allverycd时选择减分后，见中的图：
标记“硬”（硬性吸血）的easyMule2 mod 被屏蔽。
标记“软”（软性吸血）的VeryCD MOD和easyMule mod 被减分处理，允许进入上传列表。
#2 无敌稻草人

2013年4月7日周日 08:58 | 回复

@asp502010 明白了，那就减分吧，反正上传空着也空着。不过现在就算是vc的mod也只能看到easyMule了啊，VeryCD都没看到了。
#3 asp502010

2013年4月7日周日 09:28 | 回复

@无敌稻草人
VeryCD还是很多的。
我是完全屏蔽的，很多很多正规mod的用户等着我上传，哪有上传量给VC阉割驴啊～～
#4 无敌稻草人

2013年4月7日周日 10:17 | 回复

@asp502010 为啥我的列表里面大部分都是VCmod？
难道因为我的资源都是很久以前从VC上拖下来的？
现在有什么好的资源发布站么？试试发布一下看看
#5 asp502010

2013年4月7日周日 15:38 | 回复

@无敌稻草人
都是VC mod？那是因为你只是减分，而没有屏蔽！经验上来看，减分根本不是有效的惩罚措施，很快VC mod就会占据整个上传列表。

我在qvocd上发东西，这个网站上显示的资源都是网站会员发布的，没有从别的网站“抄”来的。
现在大多数电驴资源网站都是如simplecd这样，所以说在任何一个网站发布资源，很快所有电驴资源网站都会有显示，大家就都可以看到。
#6 无敌稻草人

2013年4月7日周日 15:48 | 回复

@asp502010 其实我只是想在公司尝试一下10M光纤的上传极限来的，再说屏蔽掉VC的话，上传列表一直空着挺浪费的。今天看了一下，除了VC的MOD在下学习教程意外，其他的MOD都是在下霍比特人 😯 。有空还是试试发布好了。
#7 无敌稻草人

2013年4月7日周日 15:53 | 回复

@asp502010 我说怎么觉得这个网站很眼熟呢，原来我经常上的是http://www.qvodsou.com/。。。这个图标是在太有欺骗性了。刚刚看了下，QVOCD我竟然有账号来的，抽空发布一下看看，从其他网站搬过来的资源可以发布么？
#8 无敌稻草人

2013年4月7日周日 16:57 | 回复

@asp502010 屏蔽也太有效了，几个小时过去了，上传列表里一直是空的。
#9 asp502010

2013年4月7日周日 17:24 | 回复

@无敌稻草人
我也共享不少学习资源、电子书、音乐，很多人（非VC）下载的。
重复资源最好不要发了，没什么必要，我一般找资源去ed2kers，发资源去qvocd。
#10 无敌稻草人

2013年4月7日周日 17:38 | 回复

@asp502010 那么这些资料的来源一般是什么？原创的么？
是否可以把我拥有的东西都查下源，没源的东西我就发布一下。有什么好的电骡相关的交流的地方么？
#11 asp502010

2013年4月7日周日 18:21 | 回复

@无敌稻草人
如果是原创的优秀资源当然最好，不过很多时候也不能强求原创。
其实很多电驴资源都是从（国内外的）论坛、网盘搬运来的，进而在电驴网络这个平台传播。
自己如果有一些喜爱的资源，都可以共享。共享前我都是在ed2kers这个网站上查查，看有没有别人发过（带文字介绍的）。

随着网盘的盛行和迅雷等吸血骡的压榨，emule在国内没有前几年火了，众多论坛都荒废了。
如果你有兴趣可以来百度emule吧，没什么大神，但多少有一点人气。
#12 schwarze Milch

2013年4月7日周日 20:42 | 回复

一直连接的好好的任何一个服务器，断开了以后，想再次连接，就出现you can’t connect to filtered server
但emule下次启动以后所谓filtered server又可以再连接了
各位大神求教解决方法
Mod：Mephisto 3.0
#13 vk

2013年4月10日周三 02:34 | 回复

前端家庭路由真实屏蔽gfw reset包的办法
由于中国的ISP出口路由都被国家金盾工程gfw检测，现在使用迷惑协议连接国外的emule服务器都被断开，通过检测ttl来屏蔽gfw发出的伪reset包，此代码也可以用于google等被reset包困扰的网站。
1. emule config目录下preferences.ini文件里面
DontRemoveStaticServers=1
CryptLayerRequested=1
CryptLayerRequired=1
CryptLayerSupported=1

2. emule 目录下staticservers.dat文件里面把所有常用的服务器，写在里面。

3. telnet/ssh到前端路由，必须是linux系统，而且iptables 支持 ttl-match功能，前端路由不能屏蔽icmp code 8 & code 0
touch ignore_gfw_rst_server
echo 212.63.206.35:4242,1,eDonkeyServer No2 >>ServerIPs
把静态服务器一个个写进ignore_gfw_rst_server文件中，然后执行下面代码
for ServerIPs in `cat /tmp/root/ignore_gfw_rst_server`
do
ttl=`ping -c 1 $ServerIPs | grep “ttl=” | awk -F'[: =]’ ‘{print $9}’|uniq;`
iptables -t mangle -I FORWARD 2 -i ppp0 -m ttl ! –ttl-eq $ttl -s $ServerIPs -j DROP
done;
说明：ignore_gfw_rst_server这个文件我放在/tmp/root目录下，ppp0是前端路由pppoe的设备号，当然看具体情况，可能有ppp1 类似的。

Ps:为防ISP自动换IP可以适当增加ttl数值，例如额外加入ttl=ttl+3，然后再执行iptables -t mangle -I FORWARD 2 -i ppp0 -m ttl ! –ttl-gt $ttl -s $ServerIPs -j DROP
一般来说电信不会轻易改变路由跳数，总是有家庭接到小区路由，再接到局端，认证后分配公网IPv4地址。
如果嫌弃mangel表FORWARD链效率不够高，也可以加入raw表PREROUTING链中
经本人测试电信线路，前端路由执行这个代码，一般来说neoemule 2分钟内可以用迷惑协议连接到服务器。
#14 vk

2013年4月10日周三 02:41 | 回复

@vk
echo 212.63.206.35:4242,1,eDonkeyServer No2 >>ServerIPs
这段代码写错了，应该是下面的
echo 212.63.206.35:4242,1,eDonkeyServer No2 >>/tmp/root/ignore_gfw_rst_server
#15 vk

2013年4月10日周三 02:58 | 回复

@vk
一不小心又写错了，
echo 212.63.206.35:4242,1,eDonkeyServer No2 >>ServerIPs
这段代码写错了，应该是下面的
echo 212.63.206.35:4242,1,eDonkeyServer No2 >>/tmp/root/ignore_gfw_rst_server

最终版应该是下面的
echo 212.63.206.35 >>/tmp/root/ignore_gfw_rst_server

说明：echo+空格+IP地址就行了。
#16 reduce

2013年4月10日周三 17:11 | 回复

@vk
服务器那边一样会受到RST包的，光自己这边忽略没用……
#17 vk

2013年4月10日周三 17:55 | 回复

有用的，现在好像国外服务器有检测，因为你的包比伪包先到服务器，服务器好像会扔掉伪报。只要你本机不发rst包，服务器连接就有效。
下面是我的log
2013/4/10 17:01:17: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/10 17:01:18: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/10 17:01:40: Connection attempt to “eDonkeyServer No2” (212.63.206.35:4242) timed out
2013/4/10 17:01:45: Connecting to EvilBoar (91.217.90.135:3000 – using Protocol Obfuscation) …
2013/4/10 17:01:52: EvilBoar (91.217.90.135:3000) appears to be dead.
2013/4/10 17:01:57: Connecting to UsenetNL.biz No2 (91.200.42.119:9939 – using Protocol Obfuscation) …
2013/4/10 17:01:57: Connected to UsenetNL.biz No2 (91.200.42.119:9939), sending login request
2013/4/10 17:01:57: UsenetNL.biz No2 (91.200.42.119:9939) appears to be full
2013/4/10 17:02:02: Connecting to eMule Security No1 (91.200.42.46:1176 – using Protocol Obfuscation) …
2013/4/10 17:02:03: Connected to eMule Security No1 (91.200.42.46:1176), sending login request
2013/4/10 17:02:03: eMule Security No1 (91.200.42.46:1176) appears to be full
2013/4/10 17:02:08: Connecting to UsenetNL.biz No1 (91.225.136.126:1887 – using Protocol Obfuscation) …
2013/4/10 17:02:08: Connected to UsenetNL.biz No1 (91.225.136.126:1887), sending login request
2013/4/10 17:02:09: UsenetNL.biz No1 (91.225.136.126:1887) appears to be full
2013/4/10 17:02:11: Connecting to eMule Security No2 (91.200.42.47:3883 – using Protocol Obfuscation) …
2013/4/10 17:02:11: Connected to eMule Security No2 (91.200.42.47:3883), sending login request
2013/4/10 17:02:13: eMule Security No2 (91.200.42.47:3883) appears to be full
2013/4/10 17:02:14: Connecting to PEERATES.NET (88.191.81.111:7111 – using Protocol Obfuscation) …
2013/4/10 17:02:17: Connected to PEERATES.NET (88.191.81.111:7111), sending login request
2013/4/10 17:02:21: PEERATES.NET (88.191.81.111:7111) appears to be full
2013/4/10 17:02:22: Connecting to PeerBooter (88.191.228.66:7111 – using Protocol Obfuscation) …
2013/4/10 17:02:22: Connected to PeerBooter (88.191.228.66:7111), sending login request
2013/4/10 17:02:23: PeerBooter (88.191.228.66:7111) appears to be full
2013/4/10 17:02:23: Failed to connect to all servers listed. Making another pass.
2013/4/10 17:02:23: Automatic connection to server will retry in 30 seconds
2013/4/10 17:02:25: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/10 17:02:25: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/10 17:02:27: Obfuscated connection established on: eDonkeyServer No2 (212.63.206.35:4242)
#18 reduce

2013年4月10日周三 22:15 | 回复

@vk
首先可以确认的是，服务器端没有任何过滤伪包的措施，根本没有必要为了大陆做这种事情
其次，墙的包肯定会比用户的包早到服务器，这是物理原因，不是技术原因
再有，你能连上只能说明墙有时可能漏检了，还有就是你的网络状况很差，多数服务器都拒绝你的连接
#19 vk

2013年4月11日周四 00:22 | 回复

@reduce
墙的包不可能比用户的包更早到达服务器，因为gfw规则是检测，如在屏蔽地址内，包在最后一个出口路由的旁路上被拦截，不在屏蔽规则内，在中断连接的规则内是检测，然后放行，如果触发中断连接规则，一般由3个不同的路由旁路向源地址和目的地址发出3个40字节的rst包。
这是物理原因，因为只有源地址和目的地址建立连接时，rst包才有效，你可以LAN里面做做实验，没有连接，你发给目的地址，保证目的地址把你的包都丢掉。
我的网络不差，电信光纤，到美国西部一般20几跳 100多ms延迟。
而且我这个屏蔽rst包的规则用了不是一天两天了，大半年了。一直都是这样。
#20 vk

2013年4月11日周四 00:51 | 回复

@reduce
被拒绝是正常的，一般2-3次后可以正常连接emule 服务器。连上去后可以搜索被屏蔽的关键字。
eDonkeyServer No2 (212.63.206.35:4242) 这台服务器不能搜索所有的东西。
eMule Security No1 (91.200.42.46:1176) 这台服务器可以搜索类似[]之类的。
加密连接后，墙认不出关键字，它就只能放行了。
现在只有一个缺点，单位时间内，每个IP包有效承载变小了。

我现在https google，有时候也会碰到中断连接，但是我一刷新就好了，google正常用，不管什么关键字不关键字，一百样正常。
#21 reduce

2013年4月11日周四 01:47 | 回复

@vk
看来是我表述得不是很完整造成了误会……我说『墙的包肯定会比用户的包早到服务器』是特指那个伪造的RST包而不是平时连接的包，不是建立连接的问题。
其实我是看到『因为你的包比伪包先到服务器，服务器好像会扔掉伪报』才说的。现在网络上基本都不会有认证的机制，所以才会轻易被会话劫持。正如你这个程序是通过TTL值来判断，你认为在编写软件的过程中维护人员还会专门考虑大陆的情况，然后从IP头里把TTL值之类的抽出记录下来做对比？这是不可能的，正如前段时间被伪造来源的包欺骗DNS服务器DDoS到Spamhaus一样，人家设计的时候压根就没想过（严格来说IPv4也不是没想过，只是当时认为安全是更上层协议做的）这个问题。
#22 reduce

2013年4月11日周四 01:58 | 回复

@vk
还有一个问题……
你是假设服务器会忽略这个伪造的RST包为前提而得出的结论，但根据我常年挂机的经验，现在使用迷惑协议能连接上的几率（我这边什么也没用）虽然小但并不是没有。使用迷惑协议后流量就没有特征了（注意不是加密，而是『没有特征』），自然就能搜到了（当然如果墙做的是深度检测那另当别论
然后就是eMule报告『appears to be full』其实是有几个情况……不知你有没了解过TCP协议，能使eMule产生这个错误可能是服务器发来了FIN包结束了连接（这是正常真满人服务器无法处理的情况），还有就是连接超时（就是说三次握手握到一半或者握手成功就要进行登录，忽然因为某种原因没了响应而这边还不知道还在傻等直到超时产生这个错误。看到这里你可能已经知道了，这里所说的『忽然因为某种原因没了响应』可能就是服务器收到了伪造的RST包以为你已经关闭连接了所以服务器也复位了连接。
#23 reduce

2013年4月11日周四 02:01 | 回复

@vk
至于Google的https那更是简单的情况……
原本https就是传输内容完全加密的（当然不包括IP地址和请求的域名以及证书等），中途路由根本就不知道那里面是什么内容，有时被打断了纯粹是运气问题（参见去年前年Google加密服务受干扰的事件）其实现在也还在干扰……好吧回到重点，既然是完全加密的，你搜什么中途路由压根就不知道，谈何碰到关键词切断 😀
#24 vk

2013年4月11日周四 11:09 | 回复

@reduce
一开始当emule服务器收到伪造的rst包，向连接地址发fin包，网关接受，转发给LAN内机器，机器结束连接。我第二次，第三次发起连接，就可以正常连接到emule服务器。请问这是什么原因？明显就是服务器那边已经有IP检测了，只有当双方都丢弃了伪造的rst包，才可以建立连接。
一般来说墙会发出2种伪造的包：
第一种包含tcp.flags.ack 和 tcp.flags.rst
第二种就只有tcp.flags.rst
这2种包都只有40字节。
这2种包都被我过滤了
我只接受真正服务器发出的包，所以才会建立连接。
下面我贴一段我的log给你看，眼见为实
2013/4/11 10:55:27: UPnP successfully set up forwardings for ports 4660 (TCP) and 4660 (UDP)
2013/4/11 10:55:28: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/11 10:55:28: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/11 10:55:30: eDonkeyServer No2 (212.63.206.35:4242) appears to be full
2013/4/11 10:55:31: Connecting to UsenetNL.biz No2 (91.200.42.119:9939 – using Protocol Obfuscation) …
2013/4/11 10:55:32: Connected to UsenetNL.biz No2 (91.200.42.119:9939), sending login request
2013/4/11 10:55:33: UsenetNL.biz No2 (91.200.42.119:9939) appears to be full
2013/4/11 10:55:38: Connecting to EvilBoar (91.217.90.135:3000 – using Protocol Obfuscation) …
2013/4/11 10:55:52: EvilBoar (91.217.90.135:3000) appears to be dead.
2013/4/11 10:55:53: Connecting to eMule Security No1 (91.200.42.46:1176 – using Protocol Obfuscation) …
2013/4/11 10:55:53: Connected to eMule Security No1 (91.200.42.46:1176), sending login request
2013/4/11 10:55:55: eMule Security No1 (91.200.42.46:1176) appears to be full
2013/4/11 10:55:56: Connecting to UsenetNL.biz No1 (91.225.136.126:1887 – using Protocol Obfuscation) …
2013/4/11 10:55:57: Connected to UsenetNL.biz No1 (91.225.136.126:1887), sending login request
2013/4/11 10:55:59: UsenetNL.biz No1 (91.225.136.126:1887) appears to be full
2013/4/11 10:55:59: Connecting to eMule Security No2 (91.200.42.47:3883 – using Protocol Obfuscation) …
2013/4/11 10:56:00: Connected to eMule Security No2 (91.200.42.47:3883), sending login request
2013/4/11 10:56:01: eMule Security No2 (91.200.42.47:3883) appears to be full
2013/4/11 10:56:02: Connecting to PEERATES.NET (88.191.81.111:7111 – using Protocol Obfuscation) …
2013/4/11 10:56:05: Connected to PEERATES.NET (88.191.81.111:7111), sending login request
2013/4/11 10:56:05: Lost connection to PEERATES.NET (88.191.81.111:7111)
2013/4/11 10:56:06: Connecting to PeerBooter (88.191.228.66:7111 – using Protocol Obfuscation) …
2013/4/11 10:56:09: Connected to PeerBooter (88.191.228.66:7111), sending login request
2013/4/11 10:56:13: PeerBooter (88.191.228.66:7111) appears to be full
2013/4/11 10:56:13: Failed to connect to all servers listed. Making another pass.
2013/4/11 10:56:13: Automatic connection to server will retry in 30 seconds
2013/4/11 10:56:14: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/11 10:56:14: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/11 10:56:38: Connection attempt to “eDonkeyServer No2” (212.63.206.35:4242) timed out
2013/4/11 10:56:39: Connecting to UsenetNL.biz No2 (91.200.42.119:9939 – using Protocol Obfuscation) …
2013/4/11 10:56:39: Connected to UsenetNL.biz No2 (91.200.42.119:9939), sending login request
2013/4/11 10:56:42: UsenetNL.biz No2 (91.200.42.119:9939) appears to be full
2013/4/11 10:56:47: Connecting to EvilBoar (91.217.90.135:3000 – using Protocol Obfuscation) …
2013/4/11 10:56:49: EvilBoar (91.217.90.135:3000) appears to be dead.
2013/4/11 10:56:50: Connecting to eMule Security No1 (91.200.42.46:1176 – using Protocol Obfuscation) …
2013/4/11 10:56:50: Connected to eMule Security No1 (91.200.42.46:1176), sending login request
2013/4/11 10:56:51: eMule Security No1 (91.200.42.46:1176) appears to be full
2013/4/11 10:56:52: Connecting to UsenetNL.biz No1 (91.225.136.126:1887 – using Protocol Obfuscation) …
2013/4/11 10:56:52: Connected to UsenetNL.biz No1 (91.225.136.126:1887), sending login request
2013/4/11 10:56:54: UsenetNL.biz No1 (91.225.136.126:1887) appears to be full
2013/4/11 10:56:55: Connecting to eMule Security No2 (91.200.42.47:3883 – using Protocol Obfuscation) …
2013/4/11 10:56:56: Connected to eMule Security No2 (91.200.42.47:3883), sending login request
2013/4/11 10:56:57: eMule Security No2 (91.200.42.47:3883) appears to be full
2013/4/11 10:56:57: Connecting to PEERATES.NET (88.191.81.111:7111 – using Protocol Obfuscation) …
2013/4/11 10:56:58: Connected to PEERATES.NET (88.191.81.111:7111), sending login request
2013/4/11 10:56:58: PEERATES.NET (88.191.81.111:7111) appears to be full
2013/4/11 10:56:59: Connecting to PeerBooter (88.191.228.66:7111 – using Protocol Obfuscation) …
2013/4/11 10:56:59: Connected to PeerBooter (88.191.228.66:7111), sending login request
2013/4/11 10:57:00: PeerBooter (88.191.228.66:7111) appears to be full
2013/4/11 10:57:00: Failed to connect to all servers listed. Making another pass.
2013/4/11 10:57:00: Automatic connection to server will retry in 30 seconds
2013/4/11 10:57:02: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/11 10:57:05: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/11 10:57:26: Connection attempt to “eDonkeyServer No2” (212.63.206.35:4242) timed out
2013/4/11 10:57:27: Connecting to UsenetNL.biz No2 (91.200.42.119:9939 – using Protocol Obfuscation) …
2013/4/11 10:57:28: Connected to UsenetNL.biz No2 (91.200.42.119:9939), sending login request
2013/4/11 10:57:29: UsenetNL.biz No2 (91.200.42.119:9939) appears to be full
2013/4/11 10:57:34: Connecting to EvilBoar (91.217.90.135:3000 – using Protocol Obfuscation) …
2013/4/11 10:57:36: EvilBoar (91.217.90.135:3000) appears to be dead.
2013/4/11 10:57:38: Connecting to eMule Security No1 (91.200.42.46:1176 – using Protocol Obfuscation) …
2013/4/11 10:57:38: Connected to eMule Security No1 (91.200.42.46:1176), sending login request
2013/4/11 10:57:39: eMule Security No1 (91.200.42.46:1176) appears to be full
2013/4/11 10:57:40: Connecting to UsenetNL.biz No1 (91.225.136.126:1887 – using Protocol Obfuscation) …
2013/4/11 10:57:40: Connected to UsenetNL.biz No1 (91.225.136.126:1887), sending login request
2013/4/11 10:57:42: UsenetNL.biz No1 (91.225.136.126:1887) appears to be full
2013/4/11 10:57:43: Connecting to eMule Security No2 (91.200.42.47:3883 – using Protocol Obfuscation) …
2013/4/11 10:57:44: Connected to eMule Security No2 (91.200.42.47:3883), sending login request
2013/4/11 10:57:45: eMule Security No2 (91.200.42.47:3883) appears to be full
2013/4/11 10:57:46: Connecting to PEERATES.NET (88.191.81.111:7111 – using Protocol Obfuscation) …
2013/4/11 10:57:55: Connected to PEERATES.NET (88.191.81.111:7111), sending login request
2013/4/11 10:58:04: PEERATES.NET (88.191.81.111:7111) appears to be full
2013/4/11 10:58:05: Connecting to PeerBooter (88.191.228.66:7111 – using Protocol Obfuscation) …
2013/4/11 10:58:05: Connected to PeerBooter (88.191.228.66:7111), sending login request
2013/4/11 10:58:06: PeerBooter (88.191.228.66:7111) appears to be full
2013/4/11 10:58:06: Failed to connect to all servers listed. Making another pass.
2013/4/11 10:58:06: Automatic connection to server will retry in 30 seconds
2013/4/11 10:58:08: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/11 10:58:09: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/11 10:58:32: Connection attempt to “eDonkeyServer No2” (212.63.206.35:4242) timed out
2013/4/11 10:58:34: Connecting to UsenetNL.biz No2 (91.200.42.119:9939 – using Protocol Obfuscation) …
2013/4/11 10:58:34: Connected to UsenetNL.biz No2 (91.200.42.119:9939), sending login request
2013/4/11 10:58:35: UsenetNL.biz No2 (91.200.42.119:9939) appears to be full
2013/4/11 10:58:40: Connecting to EvilBoar (91.217.90.135:3000 – using Protocol Obfuscation) …
2013/4/11 10:58:43: EvilBoar (91.217.90.135:3000) appears to be dead.
2013/4/11 10:58:44: Connecting to eMule Security No1 (91.200.42.46:1176 – using Protocol Obfuscation) …
2013/4/11 10:58:45: Connected to eMule Security No1 (91.200.42.46:1176), sending login request
2013/4/11 10:58:46: eMule Security No1 (91.200.42.46:1176) appears to be full
2013/4/11 10:58:47: Connecting to UsenetNL.biz No1 (91.225.136.126:1887 – using Protocol Obfuscation) …
2013/4/11 10:58:47: Connected to UsenetNL.biz No1 (91.225.136.126:1887), sending login request
2013/4/11 10:58:49: UsenetNL.biz No1 (91.225.136.126:1887) appears to be full
2013/4/11 10:58:50: Connecting to eMule Security No2 (91.200.42.47:3883 – using Protocol Obfuscation) …
2013/4/11 10:58:50: Connected to eMule Security No2 (91.200.42.47:3883), sending login request
2013/4/11 10:58:52: eMule Security No2 (91.200.42.47:3883) appears to be full
2013/4/11 10:58:53: Connecting to PEERATES.NET (88.191.81.111:7111 – using Protocol Obfuscation) …
2013/4/11 10:58:53: Connected to PEERATES.NET (88.191.81.111:7111), sending login request
2013/4/11 10:59:02: PEERATES.NET (88.191.81.111:7111) appears to be full
2013/4/11 10:59:03: Connecting to PeerBooter (88.191.228.66:7111 – using Protocol Obfuscation) …
2013/4/11 10:59:03: Connected to PeerBooter (88.191.228.66:7111), sending login request
2013/4/11 10:59:04: PeerBooter (88.191.228.66:7111) appears to be full
2013/4/11 10:59:04: Failed to connect to all servers listed. Making another pass.
2013/4/11 10:59:04: Automatic connection to server will retry in 30 seconds
2013/4/11 10:59:06: Connecting to eDonkeyServer No2 (212.63.206.35:4242 – using Protocol Obfuscation) …
2013/4/11 10:59:07: Connected to eDonkeyServer No2 (212.63.206.35:4242), sending login request
2013/4/11 10:59:09: Obfuscated connection established on: eDonkeyServer No2 (212.63.206.35:4242)
#25 vk

2013年4月11日周四 11:27 | 回复

@reduce
那我们不说google 我们说说维基百科，zh.wikipedia.org
维基百科，如果不过滤墙的包，访问都不正常，我过滤了以后，什么[]，[]都可以搜索。
#26 reduce

2013年4月11日周四 18:08 | 回复

@vk
那是规则问题……我也实验过，在连续40s内请求同一个IP地址触发连接重置，超过40s后墙就不会再干扰连接，个人觉得是为了减少负载。所以针对迷惑协议设置一段时间或者一定次数的干扰限制实在是正常……
#27 vk

2013年4月11日周四 23:03 | 回复

@reduce
那zh.wikipedia.org内我搜索[] 第一次被拦截，我点stop 然后refresh 立马出来了，肯定不要40秒
10秒最多了。我这个还是有效的。
#28 reduce

2013年4月11日周四 23:44 | 回复

@vk
说实话这种情况并不能说明服务器没有收到并确认RST包，只能说明可能网络问题造成包混乱没有重置而已
况且墙这种黑箱操作，有些行为永远没办法预测到，很正常

你一直强调服务器能检测出并忽略伪造的RST包，那就以此为假设
不知道你有没抓过包？如果服务器能检测出并忽略伪造的RST包，但用户却没有这种检测，那应该产生什么现象？
就是说服务器那边会依据TCP协议的重传机制发包检测客户这边的情况，但客户端这边却已经被重置连接了，正如你所说『只有源地址和目的地址建立连接时，RST包才有效』不止RST包，其它包也是，如果服务器那边不知道客户端这边连接已经被重置，是不是会继续给客户端发送包确认？
但事实上却没有抓到任何连接被重置后服务器发来的包，说明服务器那边也确认被连接重置。
#29 vk

2013年4月12日周五 00:16 | 回复

@reduce
以前tcpdump抓过，现在不用抓，前段路由log一开，grep rst 就出来了

那我建立连接 syn ack 一直都有效，也没有收到服务器发出的fin包，不管墙怎么弄，我这个方法至少有一定效果，我一直在说好像，是不确定的，我没说肯定服务器那里有检测。因为当服务器收到伪包应该中断连接的，但是我又连得上，那么我就只能说好像。不然就没法解释得通了。
#30 xxxxxxxx

2013年4月12日周五 14:16 | 回复

有没有哪位老妖弄个连打君插件呢.
#31 无敌稻草人

2013年4月18日周四 15:28 | 回复

最近准备下个《四大名著终极收藏版》，查了下源，都只有一两个完成源，所以想试试BT
用uTorrent下了半天，发现6个客户端里，有4个标记为迅雷，而且给我上传的只有迅雷的客户端，有点不明白迅雷为啥传给其他BT客户端，不传给EMULE呢？还是我理解有误？
#32 无敌稻草人

2013年4月18日周四 16:43 | 回复

额~~~挂了一下午以后，不下载只上传了。。。
#33 lyb

2013年4月21日周日 22:38 | 回复

【求助】新买的本本装的64位WIN7，安装了非阉割正版的VO.50a，后来还怕是无法支持64位而安装了一个其他的修改版，但是都不是阉割版，结果还是一样无法连接到ed2k和kad，在首次使用向导那里，检测TCP，UDP就无法连接，请大神99999999999999啊。。。与此同时的我的其他的电脑，也是安装的WIN7但是是32位的，可以正常使用驴子，这是为什么。。。。:?
#34 无敌稻草人

2013年4月24日周三 09:32 | 回复

@lyb 使用向导那里只是为了检测端口是否开放，能否获得HIGHID。看看你的服务器列表中是不是空的，KAD网络中有节点么？是否64位对骡子的时候没有影响。绝大部分32位程序都可以在64位系统下正常运行。顺便说X MOD好像有原生64版本，但是看评论貌似bug不少
#35 默默的悲伤

2013年4月26日周五 09:57 | 回复

我喜欢开源,也喜欢支持正版
不知道为什么,那么多的所谓”eMule”一味的支持eMule,
同时找出各种所谓的证据,去打击、甚至谩骂veryCD和迅雷
————————————————–
自己使用eMule盗取正版软件的同时又在去谩骂别人,这有什么区别?
我知道,在国内的大环境避免盗版几乎是不可能的
我也知道,使用eMule至少是一种支持正版开源的心态,我支持
————————————————–
只是希望更理智一些,约束一些,少一些谩骂…
#36 ghw

2013年4月27日周六 16:41 | 回复

@默默的悲伤很多迅雷用户素质更差好吧，你隔壁就有
https://www.emulefans.com/xunlei-server-ip-100802/comment-page-2/#comment-24359
引用莫斯科辱线猴
“一群穷B狗子的，迅雷离线就是好用，有种你们接着屏蔽，屏蔽一个我们再来一百个，你们的后台在哪里？SB”
“吸血？呵呵。。。时间就是金钱。使用迅雷就是花钱买时间，懂？一群臭屌，你们的时间当然不值钱。呵呵”
说到“打击”，是verycd和迅雷在打击emule，打击ed2k网络，吸emule的血好吧？别把verycd和迅雷说得像弱势群体一样
#37 LéFra

2013年4月27日周六 18:17 | 回复

这个网站页码好像有点偏差

明知道迅雷离线吸血还用的，其素质的确有待探讨
其实像上面的莫斯科辱线猴，他提了一下“吸血”，然后傻笑了下，然后继续骂别的，可见他潜意识里也对“吸血”这个话题有某种不想正面提及的感触 😀

迅雷等吸血党直接导致了国内的ED和BT资源保源能力很差，国内P2P用户大多没有上传分享意识。我在法国，有时去BT站T411下东西，那里的资源哪怕是很冷门的而且4、5年前的，都能达到大约1.7、1.8M/s的满速下载
#38 LéFra

2013年4月27日周六 18:23 | 回复

页码有偏差，点击最后回复的链接，会进入倒数第二页，而不是最后回复所在的最后一页，必须在倒数第二页点“下一页”才能查看最后一页
#39 ak47

2013年4月30日周二 12:43 | 回复

请问emule0.50a-Xtreme8.1.7z版本的电骡子，其搜索方式里 “自动” “全局” “kad” “服务器” 这几个类型里哪个最好？

现在有更好的版本吗？我觉得emule0.50a-Xtreme8.1.7z还凑合
#40 ak47

2013年4月30日周二 12:44 | 回复

@LéFra
好像现在迅雷也有上传功能了
#41 reduce

2013年4月30日周二 18:12 | 回复

@ak47
Kad
#42 无敌稻草人

2013年5月1日周三 02:17 | 回复

@ak47 本来就有好不，只不过是上传给迅雷客户端，传给其他的极少。
#43 東京奧

2013年5月2日周四 07:34 | 回复

@ak47
那個上載功能是廢的…
你設定上限成2048KB/S
但最後會因為任務自動停止而沒有上載 🙄
#44 LéFra

2013年5月3日周五 01:49 | 回复

@ak47 迅雷离线没有任何上传。迅雷软件连P2P时会给迅雷自己上传但极少给其他BT、EM客户上传，如无敌稻草人所说，这种上传也是一直都有的
#45 東京奧

2013年5月3日周五 07:41 | 回复

@LéFra
昨天充值了2年白金會員..但的確離線下載和高速通充真的很好用
#46 无敌稻草人

2013年5月3日周五 09:11 | 回复

@東京奧让人付钱享受本应该免费享受的东西，从这点来说迅雷也算是流氓中成功者了
#47 starrin

2013年5月3日周五 13:06 | 回复

@无敌稻草人迅雷离线这些服务给服务器带来的压力是非常可怕的，你可以觉得这个服务本身不道德，但是绝对不会是“本应该免费享受的东西”的。
#48 无敌稻草人

2013年5月3日周五 15:34 | 回复

@starrin 可能我并没有表达清楚，我的意思是用正规客户端获得想要的资源，并不是说迅雷等吸血方法
#49 ak47

2013年5月3日周五 16:41 | 回复

都不要互相指责

广电恨不得你们都死大家都是苦命软件，何必自相残杀
#50 无敌稻草人

2013年5月3日周五 18:52 | 回复

@ak47 哪里有指责了啊，我就是更清楚的表达我的意思，淡定，淡定