Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Hi guys, I'm Tommy.

So I've got problem with setting up a new public server for eMule for fun and advertising for my site. Lugdunum 17.15 and a 1 TB connection should do the trick. However it doesn't seem to work correctly. For starters I just forwarded one port (TCP and UDP) but are there any more that need to be reachable?

Also description and server name doesn't get loaded on eMule. No idea if people can get a high ID as I cannot do that myself, so no way to check.
สมัครufabet
What needs to be done for the remaining community to accept the server as a valid one as opposed to "fake"? Loads of servers seem to be hidden and not available on the usual server.met lists.
ufabet
Any suggestion would be greatly appreciated.

Since we had troubles with wxWidgets networking, sometime between 2.3.1 and 2.3.2 we introduced the possibility to use Boost.Asio for networking. It uses multiple threads to send data in the background. I think that somehow the packets may be put on wire in a different order than we think we send them. It's just an idea, I have no evidence, but I'll investigate the possibility.

Amule default in Ubuntu 18.04 or a new svn 10998 crash all the time.
I reproduce the error 100% of the time is I search "charada" in the search box.

This is the backtrace

Starting program: /home/tasadarf/Documentos/AmuleNNN/bin/amule
[Depuración de hilo usando libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Nuevo Thread 0x7fffe9e68700 (LWP 23759)]
[Nuevo Thread 0x7fffe9667700 (LWP 23760)]
[Nuevo Thread 0x7fffe8e66700 (LWP 23761)]
 2018-08-03 16:07:11: amuleAppCommon.cpp(335): Initialising aMule SVN compiled with wxGTK2 v3.0.4 (Debugging) (Snapshot: rev. 10998)
 2018-08-03 16:07:11: amuleAppCommon.cpp(382): Checking if there is an instance already running...
 2018-08-03 16:07:11: amuleAppCommon.cpp(413): No other instances are running.
 2018-08-03 16:07:11: ListenSocket.cpp(67): Socket de escucha: Ok
[Nuevo Thread 0x7fffdb927700 (LWP 23764)]
[Nuevo Thread 0x7fffd3fff700 (LWP 23765)]
[Nuevo Thread 0x7fffdb126700 (LWP 23769)]
[Nuevo Thread 0x7fffda925700 (LWP 23770)]
[Thread 0x7fffda925700 (LWP 23770) terminado]
 2018-08-03 16:07:11: DownloadQueue.cpp(113): Cargando archivos temporales desde /home/tasadarf/Documentos/cosa2.
 2018-08-03 16:07:11: DownloadQueue.cpp(132): Cargando archivo part 1 de 1
 2018-08-03 16:07:11: DownloadQueue.cpp(163): Todos los archivos part cargados.
[Nuevo Thread 0x7fffda925700 (LWP 23771)]
[Nuevo Thread 0x7fffda124700 (LWP 23772)]
[Thread 0x7fffda925700 (LWP 23771) terminado]
[Thread 0x7fffdb927700 (LWP 23764) terminado]

Thread 1 "amule" received signal SIGSEGV, Segmentation fault.
0x00007ffff6961ce5 in wxWindow::DoClientToScreen(int*, int*) const ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
(gdb)

Could you please send link of latest working version?
Found many fakes around...
Thanks

Any message? aMule version? OS?

The following log lines are offered by fox88, who is now the leading developer for 'unofficial' eMule clients. Also fox88 confirmed that aMule v2.3.2 and later versions are the only ones that caused the 'Wrong header' error during downloading from them.

Here's the log lines from fox88:

23.02.2018 12:29:40: Download session started. User: xx.xxx.xxx.xx 'xxxxxxx' (aMule v2.3.2,OnQueue/None/None) in SetDownloadState(). New State: 0
23.02.2018 12:39:25: Client TCP socket: Error: Wrong header; Client=xx.xxx.xxx.xx 'xxxxxxx' (aMule v2.3.2,Downloading/None/None)
23.02.2018 12:39:25: Download session ended: Disconnected: CClientReqSocket::Disconnect(): Error: Wrong header User: xx.xxx.xxx.xx 'xxxxxxx' (aMule v2.3.2,Downloading/None/None) in SetDownloadState(). New State: 1, Length: 9:45 mins, Payload: 1.90 MB, Transferred: 1.90 MB, Req blocks not yet completed: 3.
23.02.2018 12:39:41: CorruptionBlackBox: Reporting: Found client which probably send 180.00 KB of 1.93 MB corrupted data, but it is within the acceptable limit, xx.xxx.xxx.xx 'xxxxxxx' (aMule v2.3.2,OnQueue/None/None)

23.02.2018 12:38:51: Download session started. User: yy.yy.yyy.yyy 'yyyyyy' (aMule v2.4.0 [aMule SVN],OnQueue/None/None) in SetDownloadState(). New State: 0
23.02.2018 12:40:29: Client TCP socket: Error: Wrong header; Client=yy.yy.yyy.yyy 'yyyyyy' (aMule v2.4.0 [aMule SVN],Downloading/None/None)
y3.02.2018 12:40:29: Download session ended: Disconnected: CClientReqSocket::Disconnect(): Error: Wrong header User: yy.yy.yyy.yyy 'yyyyyy' (aMule v2.4.0 [aMule SVN],Downloading/None/None) in SetDownloadState(). New State: 1, Length: 1:37 mins, Payload: 5.92 MB, Transferred: 5.92 MB, Req blocks not yet completed: 3.
23.02.2018 12:42:30: CorruptionBlackBox: Reporting: Found client which probably send 180.00 KB of 3.96 MB corrupted data, but it is within the acceptable limit, yy.yy.yyy.yyy 'yyyyyy' (aMule v2.4.0 [aMule SVN],OnQueue/None/None)

Ciao ragazzi,
con Macbook Pro non riesco più ad aprire la app.
Cancello mulelock e si crea all'apertura successiva e la app crasha, non si riesce a fare nulla, vedo solo la app nel dock...
Qualcuno può aiutarmi?
Grazie.

Hi there guys,
I can't open Amule neither if I delete mulelock file...
Need help because I have a lot of important files downloading and I don't want to loose them all.
Please help me.
Thank you.

Is there any way you could create a dump of such a wrong header and/or determine exactly where it fails processing the header?

I have been successfully detected 2 Wrong header cases with the aMule v2.3.2 client, with header of 0xde and 0xa4 for each. As I mentioned before, it doesn't seem to be the same, which means it's not the symptom that aMule sent a packet with a protocol the remote client (in this case me) doesn't support.

Sorry, I didn't encountered another 'Wrong header' in 2 days. However, I've got one 'Client TCP socket: Error: Too much data sent' with an aMule v2.4.0 [aMule SVN]. That error is another indication of possible packets sent in wrong order.

Although there are normal sessions, the ones possibly with wrong order are all high-speed clients. As I assume, it might be related to 2 packets on the way to be sent got a thread conflict with another thread, while these packets finally gets there turns, which one is the first, which one is the next can be missing.

To resolve the issue, finding ways to simplify the thread conflicts logic related to upload bandwidth throttler in order to avoid such conflicts might help.