Any thoughts on this reply?: https://bugs.winehq.org/show_bug.cgi?id=42412#c23

Now here is a weird one!!
If I run tcpdump -eXXvvv > ram:test.txt and download a file from local file server over FTP (currently testing with A2065 and mtu 1500) the file gets correct md5!
And as soon as I stop tcpdump and download the same file again the md5 no longer matches...

Attached the dump file, if it gives any clues.

No. UAE only transfers the data, it has no information how the data was created or how MTU handling is done.

Does same happen with different Amiga NIC? Perhaps it is just driver weirdness..

Tested with RTL8029 with MTU 1500 and it works there too!

Also tried downloading from aminet.net with tcpdump, md5 match, without tcpdump, no md5 match...

I read somewhere that your slirp code is borrowed from Basilisk II, so I wonder if this could be something?: https://github.com/cebix/macemu/comm...7cff6c0e8e6ac3
and/or this: https://github.com/cebix/macemu/comm...5adcbc86414feb

It does not appear to be a problem, WinUAE version uses signed variables and DNS uses Win32-specific code.

If this issue can't be fixed, are there any possibility to implement tun/tap into WinUAE?
That should also fix the speed issue, with mtu 1488 I get only about 17kb/sec, which is kinda slow :-)

SheepShaver seem to already have it and also some special built Basilisk II.
I use it myself to get AppleTalk to show my ReadyNAS in the "Chooser" in Mac OS 9 or 7.

You'll need to include much more information. I don't bother to research things that sound uninteresting.

Hmm, just read that tun/tap requires kernel level stuff which Wine doesn't support, so that seems to make it a no-no...

Have now tried the same in AmigaOS 3.9 with A2065 + Slirp (no bsdsocket.library) and MiamiDX (in Wine 2.0, WinUAE 3.4) and what do you know, it corrupts files as well!
Switch back to bsdsocket.library and all is well again.
So that rules it out to being specific to AmigaOS 4.

Any easier to debug this issue when it happens in classic AmigaOS?

Probably.. But it still needs small test case. Not file transfer that takes hundreds of ethernet frames.

Had to install Roadshow Demo, because MiamiDX tcpdump, could not produce a capture that could be opened in Wireshark.

Did a small download (~70kb) from my fileserver over FTP with IBrowse and attached the results, it actually says tcp out of order in a couple of places...

Have managed to get BasiliskII for Windows to run under Wine and set it to use slirp and it has no problems downloading from local ftp or internet, no corruption of the files!

Have also run a patched version of Wine with specific tcp debug output and according to that, Wine does its networking correct. As seen here: https://bugs.winehq.org/show_bug.cgi?id=42412#c36

And we can pretty much rule out amiga os, since it happens in both OS 4.1 with Roadshow or MiamiDX and OS 3.9 with MiamiDX or Roadshow.

So, from my point of view, the problem is in WinUAE slirp, but it only gets triggered when running on Wine for Mac.

I have seen in your code on github that there is a ifdef With_Qemu_slirp in the file slirp_uae.cpp. Is it possible for you to compile WinUAE with that instead so I can test it?
And I'm guessing it can only be used for AmigaOS 4 and PPC?

Does also uaenet.device cause same corruption? (It has very different code path than hardware emulations)

Yes but it also lacks slirp_redir() = not going to happen until it is implemented.

uaenet.device is the same, corrupted files from both aminet.net and local ftp server with both IBrowse and AmiTradeCenter.
This is with AmigaOS 3.9 and Roadshow demo configured with uaenet.device...

I replaced slirp code with current Basilisk II slirp code. Not much testing done but at least DHCP seems to work. Perhaps this fixes it.

winuae.7z updated.

No, I'm afraid that didn't solve it. Tested with both uaenet.device in AmigaOS 3.9 and A2065 in AmigaOS 4. Tried to test RTL8029, but can't get any connection, despite "shownetstatus" says it got the correct IP's.

Attached logs and screenshot from trying with the RTL8029 in OS 4.

I also remembered why it was bad idea to use basiliskii slirp directly: it is not 64-bit safe.

Now original 64-bit fixed slirp is back with basiliskii updates merged. There was very little functional changes but perhaps it helps...

Well, internet works again for RTL8029 with the new WinUAE, but it still corrupts downloaded files with both RTL8029 and A2065 on OS 4.

I am running out of options. Unless there is some rarely used feature in slirp that is really broken..

Redownload winuae.7z, use -slirplog 7 command line parameter to dump full slirp messages. Perhaps there is something interesting.