OK. After working on the IPX-to-Ethernet II bridge (and UniPCemu connected from a Windows 95 client running Doom 95), I've at last managed to get the configuration working properly.

There was an issue in the driver in handling the packets from the network side, causing it to not send the packets to the Dosbox side of the connection properly (because on invalid echo request detection).

I do see now, when the game is running between the two clients (one on Dosbox IPX net and one on UniPCemu through PPP on the Ethernet II network) that before the game starts, the Windows client is spamming the network a lot, but once the game is running the Dosbox IPX starts spamming the connection hard (sending lots and lots (about 10 times or more than the other side) of 54 bytes IPX packets).

Both clients freeze a lot because of this? Is that an issue with the Dosbox IPX side(s), or is there something weird being done there?

Did manage to start a 3-player doom game (although all 3 became super slow for some reason? Perhaps because of traffic overload from one or two of the (Dosbox) clients?).

OK. Now added support for filtering based on a configurable network number (filtering out incoming packets for Dosbox clients with network number 0, network number of the client itself and network number for broadcasting (FFFFFFFFh).

But somehow the clients now refuses to talk with each other when through UniPCemu server for some weird reason? Although with the latest commits, somehow UniPCemu can't seem to get it's network number configuration in PPP straight (it worked when ran on Windows 10 without issues?).

OK. Managed to get various combinations of UniPCemu(Dosbox-X Windows 95 running Doom 95 shareware, connected to physical IPX over Ethernet II network using UniPCemu's current server latest commit) with DOS(Dosbox IPX running normal Doom connected to my current commit of ipxgw also connected to ethernet II on IPX network number 1 (https://github.com/superfury/ipxgw/tree/ipxgw-ethernetii)) Doom running:
- Doom 95 with 1-3 Dosbox IPX clients (all verified running, but slow (perhaps due to the slow dial-up connection)).
- Dosbox only with 1-3 IPX clients only (as expected, the old build of IPXGW and normal Dosbox can already do that, didn't go as far as adding a 4th Dosbox client, as that defeats the purpose of this setup).
- Dosbox with seperated networks running in parallel (2x2 players, each 2 on their own IPX network number) also ran fine (Doom players didn't affect each other).

The only remaining case (Multiple Doom 95 clients with 2 or 3 Dosbox IPX clients or without Dosbox IPX clients) seems to always fail somehow?

So tested to fail:
2xWin95 only: no reaction
3xWin95 only: no reaction
4xWin95 only: didn't test. Seeing as the 2+ setup rule seems to be at play.
3xWin95 + 1x Dosbox: detects 4 players, then waits at the position of the top-right corner of the window on Dosbox?
2xWin95 + 2x Dosbox: detects 4 players, then all Dosbox clients wait at the position of the top-right corner of the window on Dosbox?
2xWin95 + 1x Dosbox: detects 3 players, then the Dosbox client waits at the position of the 4th player on Dosbox?

So is there an issue with the DOOM95 demo when connecting multiple Doom95 clients? You'd almost think so?

Edit: Hmmm... Could it be that pcap doesn't receive it's own sent packets on the host network? That would need to add an approach similar to the ipxgw client (sending to both clients and networks at the same time) inside UniPCemu's server?
Edit: Just modified the sending of packets to always send to both the host network and loopback (to make sure it receives it's own sent packets). I've also improved the ARP replies to use the same functionality (and keep blocking sending a reply and receiving more if the loopback buffer is filled when parsing a packet received from the real network to keep parsing operating correctly (otherwise it's own packets would be lost)).
It also simplifies the sending logic to be in one function and location and the receiving logic to be in one function as well (causing the whole sending/receiving logic to be slightly simplified wrt sending packets).
Although the sending an ARP reply with a full loopback buffer can't happen if the receiver works properly, as the loopback has higher priority than the pcap receiver.
Edit: It didn't help: Doom95 still doesn't see it's other Doom95 instances? Perhaps by design or code error (using the DOS IPX setting)?

OK. So it wasn't a problem with the clients themselves or the Dosbox IPX clients after all!

The issue in this case was that the UniPCemu handling of IPX echo requests was replying to it's own requests and causing a infinite storm of requests on itself (together with being unable to tell request from replies, which is another can of worms, replying to replies).

It also fixes the heavy loaded observed from UniPCemu's clients it seems, seeing as the connection speed is normal now! 😁

The second client sees the other client now, but immediately crashes when using the WinSock method (either displaying too many duplicates of the same player or crashing immediately once obtaining information about the game!).

MS-DOS multiplayer with Windows works now (with 2 clients, 3 not tested yet).

Edit: Started improving the UniPCemu loopback and host sending a bit. It now will send the packets to the host network always (except when forcing the host network for local IPv4 loopback). There's also some extra safety with IPX echo replies having a check on the Transport control needing to be 1 or less to trigger a reply to be automatically sent by the server (matching the Dosbox behaviour and causing the other side (used in Dosbox's ipxnet ping command and ipxgw/UniPCemu allocation of IPX node numbers (a simple collision test. If any client replies, it's assumed to be in-use and the next known unallocated node number is tried (and next etc.) until no collision occurs and the IPX node number is taken after a timeout of getting no reply for the request (nobody replying = not in use))). UniPCemu itself will increase (by 1) the Transport control field when receiving an IPX packet from anyone (indicating it went through a router). Then, when checking if to send a IPX echo reply (as Dosbox does), it will check if the Transport control field is less than 2 to trigger a reply back to the sender from the allocated node for broadcasted IPX echo packets (to the broadcast address, socket number 2), unless it's from it's own IPX node number (source address being itself). Once it sends a reply onto the host network, it's setting it's Transport control field to 1, making it act like it was sent through a router to be received already (and causing UniPCemu to not send another reply for it, fixing a race condition of sending the replies to replies, which shouldn't happen).
Edit: Just put a bugfix on ipxgw, to modify source networks when the specified network is non-zero. Thus sending packets from Dosbox to the correct network, instead of to network 0 always when sending from and to network 0(replacing the source with the network assigned to the client for proper receiving).
Edit: And fixed some more bug on ipxgw's side. There were some IPX header bugs with increasing of the wrong fields when receiving (counting it as through it went through a router). Although there's currently no limit on the amount of hops (it will increase each time it's received by a client (either UniPCemu or IPXGW)).

2 player multiplayer seems to run fine (1 Dosbox MS-DOS and 1 Windows 95 UniPCemu client), but whenever I add a second or third UniPCemu client, the MS-DOS client counts the clients connected, but never starts the game (anything past 1 Windows 9x client)?

Running Dosbox's "ipxnet ping" seems to give correct results as far as I can see, seeing the other UniPCemu clients as well as itself.

So the main issue is with more than 1 UniPCemu client. They can't seem to get past the synchronize phase? Perhaps it's not finding all clients for some weird reason?

OK. With some additional UniPCemu rewriting of filters of destination and source addresses and slight adjustment on ping replies (as an echo packet), UniPCemu doesn't seem to hang anymore when using the Windows 9x combined with ipxgw Dosbox clients.

I did notice something interesting though: if using multiple Win9x clients using Doom95, it always fails, but 1-on-1 matches with Dosbox clients always work?

Hmmm... Is there any way for MS-DOS (inside a MS-DOS prompt inside Windows 95) to recognise Windows' own IPX driver when using Doom's ipxsetup program?

Edit: OK. It already does that automatically. I see it sending packets.

But oddly enough, UniPCemu isn't receiving it's own packets (at least in the main handling) it seems, at least on Ubuntu inside Virtualbox?

Just added a slight improvement on UniPCemu's (both PPP and SLIP) IPX serving.

It now will send an IPX announce packet (which is an echo reply to it's own earlier requested IPX echo request) when it's deemed the client available (the same already happens with IPv4 clients). This will prevent other clients trying to allocate from taking the node number at the same time (if other clients function correctly).

Another little new function that's been added is that the "ipxslip" protocol (which used to be a simple ipx packet sniffer) now actually 'assigns' a IPX node number just like Dosbox does. In other words, the first valid IPX packet the client receives has the autoconfigured settings for the client in the destination and source IPX address fields. The destination node and network number is the client's own IPX node/network number. The source is of course (in this case) set to the packet server's local network listener for handling echo replies (it will never respond itself, but it can be used as a simple NULL destination for requests. The only effect it has when receiving replies on that address is that it will count a node in-use if anything is received from an allocating node that isn't assigned yet, otherwise it's simply a black hole for anything sent to it (unless any physical client on the host network is listening on said server address of course)).
Basically it's the same as the ACK packet that IPXGW sends to it's clients (the same as Dosbox supports using it's own IPX allocation mechanism on it's documented IPX over UDP port). So in that way once the client receives a valid first IPX packet using SLIP (with of course the checksum having all bits set (FFFFh), otherwise it's some remaining data from the text display of the dialing process) it can look at the header and determine it's own IPX node and network numbers! 😁

And of course the autoconfigured settings of the IPX client using the "ipxslip" protocol has one manual setting applied to it as well: the configuration file for UniPCemu now has a ipxnetworknumber setting to specify the network number for the ipx clients using the "ipxslip" protocol. So UniPCemu connected IPX SLIP clients can use their own configured network number as the server administrator desires (the PPP IPX server already supported it).

Oddly enough Windows 9x PPP clients won't actually specify a IPX network number for custom allocations it looks like (even though it's documented in the PPP IPXCP protocol)? But that's an issue on Windows, not on UniPCemu or it's implemented protocols.

One nice thing this adds is that people can add easy autoconfigurating IPX clients using the SLIP protocol (all they have to do is login using a text-based dialing script (until it says "\rCONNECTED\r"), then proceed to listen for the first valid packet (all packets being encoded using the SLIP protocol) with all-ones checksum to obtain the client's own IPX node number and network address from the destination fields and consider the client properly connected (then doing anything they like by sending and receiving normal IPX packets using SLIP encapsulation).
Edit: Did some debugging and fixed some bugs with that initial packet being sent to the client only. Now it will receive the first packet with it's own IPX node and network number as the destination node (and the source node pointing to the packet server's listening address (the reserved ipx sever node number and port on a predetermined network number)). So by listening for the incoming IPX packets, by reading the first packet received it can determine it's own IPX network and node number it's been assigned. Otherwise, it can also read the text-based IPX information from the stream and determine it's own address by analyzing the sent "IPXaddress:00000000.000000000000\r\n" line that's sent before the first packet (before it received "\rCONNECTED\r".
UniPCemu also won't send an invalid "IPaddr:..\r\n" line when in non-IPv4 modes.