aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: aMule v2.3.2 and later intend to cause 'Wrong header'  (Read 528 times)

Enig123

  • Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 6
aMule v2.3.2 and later intend to cause 'Wrong header'
« on: June 29, 2018, 07:25:49 AM »

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
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 165
  • Offline Offline
  • Posts: 2725
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #1 on: July 01, 2018, 11:12:58 AM »

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

Enig123

  • Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 6
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #2 on: July 01, 2018, 07:39:43 PM »

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.
« Last Edit: July 01, 2018, 07:53:11 PM by Enig123 »
Logged

Enig123

  • Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 6
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #3 on: July 03, 2018, 07:37:32 AM »

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.
Logged

Enig123

  • Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 6
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #4 on: July 04, 2018, 09:23:02 AM »

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.
Logged

Enig123

  • Newbie
  • *
  • Karma: 0
  • Offline Offline
  • Posts: 6
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #5 on: July 08, 2018, 01:02:27 AM »

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:

Quote
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)
Logged

GonoszTopi

  • The current man in charge of most things.
  • Administrator
  • Hero Member
  • *****
  • Karma: 165
  • Offline Offline
  • Posts: 2725
Re: aMule v2.3.2 and later intend to cause 'Wrong header'
« Reply #6 on: August 18, 2018, 09:51:45 PM »

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.
Logged
concordia cum veritate