WinUAE/Wine and networking on OS 4

[PBobbenB]

Hi!

Have recently started to fiddle with WinUAE 3.4.0 under Wine 2.0 (on Mac OS 10.11) with OS 4, after testing the new Amikit 9.
Everything works fine, except for networking.
The issue is that the transmission of data seems to get damaged, files downloaded are corrupted, images in the web browser are also corrupted.
Currently using A2065 network card, but have also tried RTL8029 PCI with Mediator 4000Mk2 and Slirp NAT and Slirp open ports, but with the same results.

Is this something to be expected when using Slirp with Wine?

Kind regards

I use Slirp+openports and it just works. Using WinUAE 3.4.0 64bits on Wine64 2.0 but on Linux. I'm not sure if/how it works different on Mac OS X.

[PBobbenB]

What's the best way to get netlogs from WinUAE?
A commandline switch or? The normal log doesn't seem to contain any specifics about network stuff.

[PBobbenB]

Managed to find the command line option -slirplog x

So, here are some logs with -slirplog 2 and a screenshot of the corruption.
The first bit of the slirp output is from visiting IBrowse homepage and the remaining from visiting AmigaWorld.net.

This time I tried WinUAE 3.3.0, which also has the same issue.

[Toni Wilen]

I have no idea what slirp log means

Could you try something very simple, like having something on LAN that can be accessed using telnet? There are too many unknown variables when accessing the net. (and not using OS4..)

Same behavior when using 32-bit or 64-bit versions?

[PBobbenB]

Console output from Wine:
fixme:winsock:set_dont_fragment IP_DONTFRAGMENT for IPv4 not supported in this platform.

Does this have anything to do with my problem?
I have seen some mentions of fragment stuff in the slirp code for WinUAE...

[PBobbenB]

Yes, same issue with 32 and 64bit Wine/WinUAE.

No issues with Amikit 9 which uses Wine 2.0, but that is OS 3.9 with bsdsocket.library emulation and that doesn't use any slirp, right?

So, the issue is only in OS 4 with slirp...

[PBobbenB]

Here is the output of downloading a file from my ReadyNAS via FTP with Wine 2.0 and WinUAE 3.4.0 (-slirplog 2), all 32bit and OS 4. Same uae config as before.

Checked md5sum and they don't match and also the file size doesn't match:
On server: 14003589 bytes
Downloaded: 14003571bytes

[Toni Wilen]

Perhaps different MTU value in OS3 vs OS4 TCP stacks?

[PBobbenB]

Well, Ranger in OS 4 reports Stack: 1500 Hardware: 1500
What OS 3 has with bsdsocket.library emulation, I have no idea.

Anyway, I found another log option: -a2065log
maybe that is of more help.
Found it from this thread: http://eab.abime.net/showthread.php?t=55564

[PBobbenB]

Made another -a2065log with WinUAE 3.4 in Windows XP in Parallels Desktop, same config as in Wine. First bit is from checking AmiUpdate, then downloading a 1.3mb file from my ReadyNAS over ftp, same procedure with the previously attached log.
Ranger reports same 1500 mtu as in OS 4 under Wine.

[PBobbenB]

The only thing that looks weird in the logs is this:
7990: 'slirp_inbound' 00:80:10:32:33:34 # From WinUAE in Parallels Desktop, which works.
A2065: 'slirp_inbound' 00:00:00:32:33:34 # From WinUAE in Wine, which corrupts.

Both are set to Slirp + Open ports.

Whoops, I was running WinUAE 3.3 in Wine, and after updating to WinUAE 3.4, it now says the same as the Parallels Desktop version:
7990: 'slirp_inbound' 00:80:10:32:33:34

[Toni Wilen]

I got some (possibly) good news, Amikit author found out that setting Amiga-side MTU to 1496 (or smaller) fixed the problem.

For example with RTL8029 add MTU=1496 to SYS:Devs/NetInterfaces/RTL8029 file.

I have no idea why 1500 does not work under MacOS, even when accessing server in same LAN.

[PBobbenB]

Well, tried A2065 with 1496 and 1400 in it's mount file in NetInterfaces, no go.
Also tried RTL8029 with 1496 and then 1200, but still no go.

***
One other thing I remember was when downloading a file from my fileserver with mtu at default value (1500), the downloaded file was some 20 bytes or so smaller than the original and with mtu 1496 it was two bytes smaller, so I tried with 1494, and it was one byte smaller, then tried 1492, 1490, 1486, but still one byte short! Also, when going down in mtu size, the transfer speed got really slow, like about 13kb/s...
***

Do you know what kind of config Amikit author was using?
Wine version, Mac OS version, WinUAE version and AmigaOS version?

[PBobbenB]

Is this anything useful?: https://github.com/qemu/qemu/commit/...ba7dc84677be55

[Toni Wilen]

I don't think so. Even if it is "wrong", wine should transparently convert it.

[PBobbenB]

What do you think is the best way to debug this issue?
Any special setup with wireshark perhaps?
And who do you think is at fault here, Wine or Qemu slirp or maybe WinUAE? ;-)

[Toni Wilen]

WinUAE does not use QEMU slirp. It probably is wine missing feature. Or something.

btw, I can't even find "set_dont_frag.." in wine sources.

[PBobbenB]

I found it:

imacen:wine-2.1 bobben$ grep -r set_dont_fragment .
./dlls/ws2_32/socket.c:static BOOL set_dont_fragment(SOCKET s, int level, BOOL value)
./dlls/ws2_32/socket.c: return set_dont_fragment(s, IPPROTO_IP, *(BOOL *)optval) ? 0 : SOCKET_ERROR;
./dlls/ws2_32/socket.c: return set_dont_fragment(s, IPPROTO_IPV6, *(BOOL *)optval) ? 0 : SOCKET_ERROR;
./dlls/ws2_32/socket.c: set_dont_fragment(ret, unixaf == AF_INET6 ? IPPROTO_IPV6 : IPPROTO_IP, FALSE);

[Toni Wilen]

Yes but those have nothing to do with the log message.