DenYoNet - Data corruption on FTP transfers

Страница 1/2
| 2

By Louthrax

Prophet (2082)

Аватар пользователя Louthrax

20-06-2019, 21:23

Hi all,

I've been struggling during 2 weeks with a strange problem on my DenYoNet: downloading big files on the MSX side with FTP (using the GET command) is always showing some corrupted bits.

On a 32MBytes file, I'm usually getting something like 200 corrupted bits.

This happens both with Konamiman's FTP and my SofaFTP client. I also tried active and passive mode, different buffer sizes, with always the same corrupted result.

The weird thing is that I observe no corruption at all using Konamiman's SMB server (OBSOSMB.COM). The main difference with the SMB protocol is that it's using a single connection at a time (at least I think so...), when FTP is requiring 2 open connections (one for status / command and the other one for data transfer).

And the even weirder thing is that the corrupted bits in FTP mode are always located at addresses in the form 0x??????F? !

I have been able to reproduce the problem on my turboR and my Zemmix Neo MSX (also tried in non-turbo/Z80 mode).

That's driving me crazy (and worst of all I have kind of the same problem at work with a CAN network, but I won't bother you with that here Smile).

I have 3 suppositions on the origin of the problem:

  1. My DenYoNet has a hardware problem of some kind.
  2. All DenYoNets have a design problem causing corruptions when 2 connections are opened at the same time.
  3. There's a software problem in the low-level UNAPI implementation (regarding the W5100 chip and several connections opened at the same time).

I have not been able to reproduce the bug with the same FTP clients on GR8Net in UNAPI mode.

I do not believe in an FTP client code bug (the download loop is pretty simple: read from UNAPI and write to file).

Did anybody experienced the same thing as me ?
Should I throw my DenYoNet away ?
Does this also happen on the recently produced Brazilian DenYoNet-like cartridges, or on an ObsoNet cardtridge ?

Let me know, any hints are welcome Smile

EDIT: I've seen that an OBSONET 1.2 Firmware had been released in the past. Would this one also work on DenYoNet (maybe it could help to spot if the difference comes from the firmware ?). And would an FTP client work with this one ?

Для того, чтобы оставить комментарий, необходимо регистрация или !login

By Grauw

Ascended (8455)

Аватар пользователя Grauw

21-06-2019, 09:19

Doubtful, ObsoNet doesn't use the WD5100 chip. The GR8NET is more similar in that regard. It also sounds like a fw bug to me...

By edoz

Prophet (2172)

Аватар пользователя edoz

21-06-2019, 10:58

The DenyoNet cannot handle big transactions correctly. It seems a hardware bug. I think Yobi told me this in the past on the fair, something with buffers or so. while we where testing with SymbOS and networking we had the same issues. GR8NET does not have those issues.

By Grauw

Ascended (8455)

Аватар пользователя Grauw

21-06-2019, 11:56

Since SymbOS doesn't use the UNAPI BIOS driver (right?), I guess that rules out a firmware bug...

By raymond

Champion (389)

Аватар пользователя raymond

21-06-2019, 18:09

Sounds like the same issue I have with SofaFTP see: SofaFTP Bug Report Thread

By Louthrax

Prophet (2082)

Аватар пользователя Louthrax

21-06-2019, 19:29

Thanks guys for the feedbacks.

Raymond, your problem was with a GR8Net right ? It's something different I guess. It might be solved by the next version of SofaFTP that I was preparing (lots of refactoring and support for more types of FTP servers). I did not release this version because I was assuming the bit corruption problem was caused by a bug in y code...

Edoz, I'm curious about the buffer thing mentionned by Yobi. The W5100 has 4 buffers that can be configured for each connection, I was a bit afraid that they could overlap, but even when reducing my requests to 128 bytes, the problem was still the same. I'll try to contact him to see if he can give some clues.

Also, the fact that it's clearly bits that are corrupted (not entire bytes), makes me thing the problem is hardware (a software bug would most probably corrupt entire bytes or memory areas...)

I'll restrain myself to using my DenYoNet as a SMB server for now (which is already amazing enough, except you miss the recursive update and the need to do your transfers from the PC side).

By Manuel

Ascended (15754)

Аватар пользователя Manuel

22-06-2019, 00:10

Louthrax: I hope you can work it out with Yobi. I'm sure he's willing to help.

The only MSX network card I own is a DenYoNet, so I need this fixed! ;-)

By Louthrax

Prophet (2082)

Аватар пользователя Louthrax

22-06-2019, 01:12

Manuel wrote:

Louthrax: I hope you can work it out with Yobi. I'm sure he's willing to help.
The only MSX network card I own is a DenYoNet, so I need this fixed! ;-)

Yeah, I hope so Smile

Still talking about DenYoNet, I tried to use the SNTP.COM server to set the date of my Zemmix at startup (because it has no RTC memory)... and it failed. I tried different NTP servers, with no success (always getting a "the time server did not send a reply"). Would anybody have a working IP for DenYoNet ?

By Meits

Scribe (5538)

Аватар пользователя Meits

22-06-2019, 02:12

While doing the same for gr8net I found out a lot of ntp servers are either dead or disfunctional so put the default russian server back and (and this might be a gr8net only thingy) then I fixed the deviation with correcting the UTC region.
ntp4.stratum2.ru (which is 88.147.254.230 when pinging it).

By ducasp

Master (153)

Аватар пользователя ducasp

22-06-2019, 03:00

I use pool.ntp.org, most IPs returned by it work fine for me (even though I don't use a Denyonet). Also, don't know why, but I needed to set the time zone in an environment variable, it didn't work as a command line parameter.

By edoz

Prophet (2172)

Аватар пользователя edoz

23-06-2019, 12:47

Louthrax wrote:

Edoz, I'm curious about the buffer thing mentionned by Yobi. The W5100 has 4 buffers that can be configured for each connection, I was a bit afraid that they could overlap, but even when reducing my requests to 128 bytes, the problem was still the same. I'll try to contact him to see if he can give some clues.

Im not sure but maybe it helps to keep the buffers full. On the GR8NET you have this basic command:
_NETVARWTH(,1024) it fills the buffers i think. If the buffers are filled the Wiznet ask the sender to wait until the wiznet can handle data again. (To avoid data corruption) But i'm not sure completely ..so better to ask Yobi about this. But it could help to trick arround the issue but will slower the processing. (I thought it was a 5100 issue)

Страница 1/2
| 2