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?

[midwan]

I've implemented a fix, which might resolve these errors.

I've only tested it with one simple tool here (sntp -> https://aminet.net/package/comm/net/sntp) which was giving me errors when it tried to open a socket and set a receive timeout (which sounds like what most of these issues are about).
It seems to work correctly after my fix above, so I think this is an improvement. Nothing seems to be negatively affected by my changes, so fingers crossed (or as they say in Sweden, "thumbs hidden").

Please test when you get a chance and let me know?

[giantclambake]

I tested sntp as mentioned in master, it seemingly works fine now... (was failing in 7.0)...

frames 10, 11 --- ask NS for IP of se.ntp.pool.org => NS replies with IP
frames 12,13 --- sntp client queries server => ntp server responds with query data

Note: this is an NTP protocol query, using assigned port :123

The program 'Dynamix' still fails as before, with no improvement...

Same 3 frames .... this is a SYNC conversation that never (seemingly) completes (3 way handshake)...

Considering the server doesn't reply to the last sent frame from the client, and given that WinUAE seemingly gets further than this, likely the next test will be to capture packets from the same scenario (using Dynamix in WinUAE), and compare the data ...ie; are we forming the 3rd frame correctly? Should we do something else after this frame is sent?...

FTR, the bsdsocket layer still works as before (well, better than before really considering sntp now works ;)

[midwan]

Thanks for the feedback!

I'll try to run Dynamix on WinUAE under the debugger, to see what's happening, then compare that with Amiberry. Maybe I can find what fails.

[giantclambake]

...same test in WinUAE v5.3.1 ....

As you can see, client instantiates a HTTP connection to server, after the ACK is sent to server..

...might help you find where it's coming unraveled.... ;)

[papa923829]

I'm not sure if this is obvious, but what version do I need to use to test the latest patch here? Or do I need to build it from git myself?

[midwan]

For now (until a new release is published), you'll need to build it from source.

[giantclambake]

Retested, still broken ~ HTTP connection to server not starting...

[midwan]

Yes, nothing more was done regarding this. I have a separate branch in testing with, but it's not there yet.

[papa923829]

I have tested the recently released 7.0.0-RC3.
I have started the dynamite Server (DServer) and it reports it is connected to the GLS and is online.
The global Server List is (still) not working, neither it is possible to connect via 127.0.0.1 to the server (which partially works with WinUAE (it does , but you get kicked after 10 seconds).

Also I have tried to use the now enabled uaenet.device. It seems I can connect with MiamiDX to the internet , but when I start Dynamite Server, Amiberry freezes completely. You cannot even ungrab the mouse anymore. You have to kill it from "outside" (like switch to different VT - ctrl+alt+F3 - and kill amiberry from there). But I suppose this is a complete different problem.