WinUAE/Wine and networking on OS 4

[PBobbenB]

This perhaps:

imacen:wine-2.1 bobben$ grep -r DONTFRAGMENT .
./dlls/ws2_32/socket.c: DEBUG_SOCKOPT(WS_IP_DONTFRAGMENT);
./dlls/ws2_32/socket.c: FIXME("IP_DONTFRAGMENT for IPv4 not supported in this platform\n");
./dlls/ws2_32/socket.c: FIXME("IP_DONTFRAGMENT for IPv6 not supported in this platform\n");
./dlls/ws2_32/socket.c: FIXME("IP_DONTFRAGMENT for IPv4 not supported in this platform\n");
./dlls/ws2_32/socket.c: FIXME("IP_DONTFRAGMENT for IPv6 not supported in this platform\n");
./dlls/ws2_32/socket.c: case WS_IP_DONTFRAGMENT:
./dlls/ws2_32/socket.c: case WS_IP_DONTFRAGMENT:
./dlls/ws2_32/socket.c: /* ensure IP_DONTFRAGMENT is disabled, in Linux the global default can be enabled */
./dlls/ws2_32/tests/sock.c: err = getsockopt(s, level, IP_DONTFRAGMENT, (char *) &value, &size);
./dlls/ws2_32/tests/sock.c: err = setsockopt(s, level, IP_DONTFRAGMENT, (char *) &value, size);
./dlls/ws2_32/tests/sock.c: err = getsockopt(s, level, IP_DONTFRAGMENT, (char *) &value, &size);
./dlls/ws2_32/tests/sock.c: err = setsockopt(s, level, IP_DONTFRAGMENT, (char *) &value, size);
./dlls/ws2_32/tests/sock.c: err = getsockopt(s, level, IP_DONTFRAGMENT, (char *) &value, &size);
./dlls/wsock32/socket.c: case 9: return 14; /* IP_DONTFRAGMENT */
./include/winsock.h:# define IP_DONTFRAGMENT 9
./include/winsock.h:# define WS_IP_DONTFRAGMENT 9
./include/ws2ipdef.h:#define IP_DONTFRAGMENT 14
./include/ws2ipdef.h:#define WS_IP_DONTFRAGMENT 14

[Toni Wilen]

Ok, so that FIXME() macro includes the function name. Anyway, this confirms it is feature that is not (yet) supported.

[PBobbenB]

And slirp needs the fragment stuff?

But how did Amikit dude manage to get it to work, did he run it under Linux or what?

[Toni Wilen]

Networking stuff can be weird?

[PBobbenB]

No shit

[Toni Wilen]

Hmm... (Partial) IP_DONTFRAGMENT was implemented very recently (December 2016). Perhaps it has nothing to do with this problem after all..

It may also explain missing macos support, no one has not yet reported (and noticed) that IP_DONTFRAG (or IP_MTU_DISCOVER and friends) are not defined in some platform specific file or something.

[PBobbenB]

Ok, well I might give it a go and submit a bug report to them then :-)

[PBobbenB]

Bug reported, let's see what they have to say:

https://bugs.winehq.org/show_bug.cgi?id=42412

Check out comment nr 10, might that be something?

[Toni Wilen]

WinUAE knows nothing about connections, it only sees ethernet frames.

It is just a "dummy pipe", ethernet frames from emulated NIC hardware go to slirp, frames that slirp returns go back to emulated NIC.

btw, bug report probably should mention that it seems to be MacOS specific, at least Linux works fine.

[PBobbenB]

Have now tested in Linux as well, and for me it doesn't work there either.

Tested with Ubuntu Linux 14.04 64-bit on a PC and Wine/Wine64 (2.1) and WinUAE/WinUAE64 (3.4.0) but still corruption.

[PBobbenB]

I found the reason Amikit guy got the network working, he uses the qemu dll from FS-uae!
So the qemu dll is involved after all.

[Toni Wilen]

WinUAE never uses QEMU slirp, it always uses built-in version.

[PBobbenB]

Then why does it work with FS-uae dll?

[Toni Wilen]

Originally Posted by PBobbenB

Then why does it work with FS-uae dll?

Different QEMU PPC emulator version? Check logged version numbers.

[PBobbenB]

Yes, of course they are different version, but something in the code obviously is different that makes it work in fs-uae version but not winuae version.

[PBobbenB]

Hmm, I spoke too soon, tried with the latest fs-uae version dll and no, still corruption, what the holy h*ll is going on??

[Toni Wilen]

Originally Posted by PBobbenB

Yes, of course they are different version, but something in the code obviously is different that makes it work in fs-uae version but not winuae version.

QEMU version should not be different. Unless someone finally bothered to update to latest QEMU. (Last time it was attempted: PPC emulation become unstable and slow..)

Originally Posted by PBobbenB

Hmm, I spoke too soon, tried with the latest fs-uae version dll and no, still corruption, what the holy h*ll is going on??

I have no idea.. I guess next step is find some simple way to duplicate it and then dump raw etnernet frames to log and check them from corruption..

Unfortunately anything after NIC emulation (=OS4 driver and tcp stack) is practically a black box

[PBobbenB]

Originally Posted by Toni Wilen

QEMU version should not be different. Unless someone finally bothered to update to latest QEMU. (Last time it was attempted: PPC emulation become unstable and slow..)

Well, the QEMU version is the same (2.2.0) but the api is newer (3.8.2).
But currently is doesn't seem like that is the problem fix either.

[PBobbenB]

Made some more capturing of netlogs, but I don't know if it's of any use, but I thought I give it a try anyway.

The first log "Netlogs from Windows" is WinUAE 3.4 in Windows XP under Parallels Desktop, where I have wiresharked (in windows) and tcpdumped (in AmigaOS) while downloading a ~500Kb file from local fileserver over FTP. This is with RTL8029 and default mtu 1500, with matching file size and md5.

Second is "Netlogs from Wine 1488" which is Wine 2.0 and WinUAE 3.4 (FlowerPot for Mac) with wireshark capture (in Mac) and tcpdump (inside AmigaOS).
Same file from local fileserver over ftp and same RTL8029 but with mtu 1488.
Matching file size and md5.

And the third is the same setup/procedure as the second one but with mtu 1500 and this time matching file size but wrong md5.

[PBobbenB]

Made some more logs from Linux and it seems to be working after all, not sure how I missed that in all the excitement...

First log "1488" is from Ubuntu 16.04, Wine 2.1 and WinUAE 3.4, where I have wiresharked (in Linux) and tcpdumped (in AmigaOS) downloading a 500kb file from local file server over FTP. With RTL8029 and MTU 1488, matching file size but wrong md5 sum.

Second, same procedure/setup as first except MTU 1500 and now the md5 matches. Also tried with A2065 with 1500mtu and switched back to WinUAE PPC plugin (from fs-uae PPC plugin) and md5 matches.

So it works in Linux after all, clumsy me!

Maybe the image corruption in IBrowse threw me off, which didn't improve despite reloading, only emptying the cache solved that.