留言板

這裡是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 哪裡有指責了啊，我就是更清楚的表達我的意思，淡定，淡定