Networking / bsdsocket.library not working correctly

[papa923829]

I have tested Amiberry (5.7.2 and preview 6.3) and tested my old Saved AMIGA OS Installation from my AMIGA past.
I have set up an AMIGA 040 with normal speed and with bsdsocket.library, RTG and stuff.
It booted all fine.
I started a game: dynAMIte and clicked on global server list - it should connect to an Server. And here the problem appears. It does not. It tries forever. Also when I start the server locally, I cannot connect to 127.0.0.1.

I have tested other Software:

• Ibrowse seems to work fine
• AmiTradeCenter seems to work fine
• AWeb seems to work fine
• BlackIRC seems to not work correctly

I don't know how to report properly what works fine and not, also why it does or does not.
However I tested the exact same configuration with WinUAE and it worked correctly. It connects within seconds and also connecting to 127.0.0.1 works fine.

My System is Linux/Debian Bookworm X86_64.
I tested it on other systems as well, but there was not change of this behavior.
I also tried to connect with MiamiDX/A2065 emulation but it didn't work as well. MiamiDX couldn't retrieve an IP.

[midwan]

The bsdsocket.library emulation is largely based on FS-UAE's implementation, since WinUAE's was Windows-specific. Unfortunately, it looks like BlackIRC doesn't connect under FS-UAE either, so there are obviously some issues with the implementation.

[papa923829]

The bsdsocket.library emulation is largely based on FS-UAE's implementation, since WinUAE's was Windows-specific. Unfortunately, it looks like BlackIRC doesn't connect under FS-UAE either, so there are obviously some issues with the implementation.

Ahh that explains I had the exact same issues with FS-UAE.

[midwan]

I'll have to take a deep-dive into it and see if I can improve it, but it will probably have to wait a bit. :)

[giantclambake]

FWIW I had a look at this using wireshark, and it gives me the impression that we're failing identd (RFC1413) ...that is, I see the initial connection negotiation, and then the remote server sends a packet that we never reply to. I can probably check this further (I know an IRC admin that will look at connection logs for me) ~ I'll need wait until he's back from holidays =)

edit: wrong, it's failing before anything like that...I did however getting it running to a local server (start server first, then launch client)...

....I'll have to grab a pcap with it running in winuae/wine, and see what differs wrt the initial client>server response...

[giantclambake]

Hmmm...okay...wrt 'DYNAMITE' pretty easy to see what's not happening ; bit harder to divine why...

That's wireshark pcap using WinUAE v5.3.0 and a clone of the ClassicWB-P96 setup I use for this stuff.

The first 3 exchanges are the client<>server auth, with the client sending an ACK upon completion...// same in amiberry

...then, the client side instantiates a HTTP/GET packet to the server, and the data resources are retrieved in this manner, to build/populate the server list window that appears at the client end.

In amiberry, this HTTP/GET packet is not seemingly generated, nor transmitted to the server. Eventually the server end calls a timeout, and it's wash, rinse, repeat ad infinitum. I wouldn't expect it to be the bsdsocket.layer's job to generate that packet ....(unless it is being generated but ignored?)....

....the behavior wrt a 'Local' connection is the same in WinUAE as in amiberry ~ you have to launch the 'DServer.exe' process first, for 'Local' connection to work in the client....

....interestingly, (could be a locale/timezone thing), even though the server list window does pop under WinUAE, and lists 2 servers, neither was apparently responding (retransmission packets) and could not be connected to ... so I couldn't confirm whether or not online gameplay actually worked..hmmm...

@papa923829 -- could you connect to either of these servers?

[papa923829]

Alright. I've spend some time at that weekend to find out whats going on.
I'll try to explain everything as good as I can - but in the end I'm afraid that amiberry is "not the only problem" here.

I tested amiberry (standalone) - I tested WinUAE and installed MorphOS on qemu - and even asked old AMIGA Users to test it.

1. First AFAIK nobody could even connect to the above servers. neither with WinUAE nor with MorphOS (native)

2. Amiberry: Connecting to the dserver from dynamite doesn't work when you use hostname/localhost/127.0.0.1/internal-server-ip --- but works when you use the button "local" - I really don't know what the difference is.
   When you start the dserver the server is visible in the GLS-network - means the server generally connect to the network
   You can see that happens within dserver in the status log.

3. WinUAE: connecting to the dserver as 127.0.0.1/localhost/hostname/local-ip works(!) but the dserver kicks you with pingtimeout. Even though you can play in the 15 seconds and the game feels "normal"
   Outsiders (other user on the internet) can "connect" (you see them on the dserver) but the client is still connecting and they can't play - the are also kicked with pingtimeout.

4. MorphOS on QEMU: connecting to the dserver as 127.0.0.1/localhost/hostname/local-ip works(!) but the dserver kicks you with pingtimeout. The small difference to WinUAE here is, the client doesn't connect as well - no matter if I do it or outsiders.
   Also different: while the dserver seems active - it is not seen in the GLS server and it doesn#t report in the dserver that it is connection. This is probably due to networking problems with qemu. Unfortunately I'n not that familiar with it.

I hope this was kind of clear. So while amiberry has the most problems here, the main problems probably comes from the game/Dynamite itself. A pingtimeout while connecting from localhost makes it look very strange.

So considering the same behavior happens with WinUAE and MorphOS it looks like WinUAE does pretty much everything right. Means if amiberry would "behave" like WinUAE, the network support surely would improve.

Just in case if you think you want to test "MorphOS on qemu" to have a "more native environment"
You can install it for free. The 30min demo-time is not a problem. Enough for testing.
When the system is installed on a qemu-file hdmos.img and you need the file: openbios-qemu.elf
You can get it from here and also other help http://zero.eik.bme.hu/~balaton/qemu/amiga/

qemu-system-ppc -machine mac99,via=pmu -m 2048 -vga none -device sm501 -boot d -prom-env "boot-device=hd:,boot.img" -bios openbios-qemu.elf -device ide-hd,drive=hd-drive,bus=ide.0 -drive file=hdmos.img,if=none,id=hd-drive,format=raw -serial stdio -nic user,hostfwd=tcp::6318-:6318 -nic user,hostfwd=udp::6318-:6318

If there is anything I can do to further help you feel free to ask. I'm happy to assist.
And thank you for your time to look at this issue.

[giantclambake]

Thanks for checking, that's aligned with my findings ; there's more to it than just amiberry getting it wrong. And that's with the winuae based bsdsocket implementation, as well as the bsdsocket code amiberry uses from fs-uae. That makes it hard...

To be clear, when I was referring to failed identd above, that was wrt the blackIRC client...(it is failing there as well ;)

[giantclambake]

Looking at the wireshark logs, this roughly concurs with what I'm seeing -> https://objfw.nil.im/tktview/4c4b0ddef1

...that is, if waitselect() is ignoring the timeout and waits forever, that would readily explain the wireshark traces I see...

@midwan .... is this still an apparent problem wrt bsdsocket code used in amiberry?