Print

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

[Enig123]

Hi,

Is there any fundamental changes from aMule v2.3.1 and v2.3.2? I have noticed some remote clients (not all) labeled as v2.3.2 or v2.4.0 svn tend to cause 'Wrong header' error to my eMule mod while downloading from them.

I have eliminated as many bugs in my mod's codes as possible, still there're these clients cause 'Wrong header' error from time to time. Since the errors now only occured with v2.3.2 and later aMule clients, I am tend to believe there may have some regressions from v2.3.1 to v2.3.2, related to sockets maybe?

Regards,
Enig123

[GonoszTopi]

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

[Enig123]

I will try to output the header to see if it related to some specific number.

But I doubt it be the case. Since in some cases the Wrong header error followed with a packed packet decompression error. My best guess is that the order of sent packets were scrambled, but I don't have a clue how it can happen.

[Enig123]

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.

[Enig123]

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.

[Enig123]

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)

[GonoszTopi]

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.

[Enig123]

The 'Wrong Header' issue of aMule v2.3.2 and later is prone to cause corrupted downloading data. My observation is, it will causing corrupted data whether or not the packet is compressed.

For what I understand, it could possibly indicate that the origin of this issue may reside in somewhere BEFORE packet being compressed, if it's about to be compressed, since even correctly uncompressed data turned out to be corrupted.

I am not 100% sure if the interpretation is correct though. Hope this will help you guys debugging solving this issue.

[Enig123]

Since I've been reading I/O Completion Ports recently, this sentence just caught my eye and I think it may be related to the bug after aMule introduced ASIO mechanism:

Please note that while the packets are queued in FIFO order they may be dequeued in a different order.

which is from the https://docs.microsoft.com/en-us/windows/win32/fileio/i-o-completion-ports.

Is it possibly due to that when one sending action is competed, the next active thread in pool initiated another sending, while there's another sending already 'in the way' while not necessarily get ahead of the new sending?

Not sure how to keep the sending sequence order in ASIO's contents though, just some thoughts.

[Vollstrecker]

I don't think that MS switched to everything is a file. When you receive parts, they get written to disk if they are correct, that is where the file-io happens. A wrong header occurs much earlier in this process.

Is it possible for you to a log like "Got xxx expected yyy"?

[Enig123]

I don't think that MS switched to everything is a file. When you receive parts, they get written to disk if they are correct, that is where the file-io happens. A wrong header occurs much earlier in this process.

Is it possible for you to a log like "Got xxx expected yyy"?

You may misunderstand my point. The receiver side (eMule client as I mentioned earlier) has ruled out it's fault, since only clients that send packets that can cause 'Wrong header' while downloading are aMule v2.3.2 or later.

I was trying to understand how could ASIO cause such trouble sending data, on the remote client (sending) side.

[Vollstrecker]

Maybe I missinterpreted your link, because it is about file-io. You get an header error, which is either an error from the network-paket, or from the received part. That's why I asked if it is possible to get a more precise output.

I never used emule, so I don't know if anything like that is possible at all with it. Maybe you could use wireshark to catch packets that cause the error.

[Enig123]

I am not sure if this bug is platform related, but it's very likely to be windows related. Is there a way to disable ASIO for windows compiling?

[Vollstrecker]

Sure, just don't provide boost and it will use wxSockets.

[Enig123]

As was expected, the latest 2.3.3 still has the bug.

During recent rewrite my download bandwidth throttler algorithm, it was discovered that certain throtterler pattern can mitigate this issue to a extend, but not be able to eliminate it. Most probable situation to trigger this issue seems to be that the receiving on remote side was delayed a little somehow.

Remote side codes changes would not be able to fix this issue though. I really hope some developer can dig into this issue and find a fix to it.