OK, looking at Dosbox, it looks like it might simply be sending an empty echo packet, and if it returns it's already allocated(and after allocation it's sending echo packets back when receiving them on the client)? So if it's available, it receives the echo back within a time limit? Otherwise, try the next node number? Would that be correct behaviour?
Edit: Although care would need to be taken not to send an echo packet to address 0, since the other servers (as far as I understand the IPXGW source code) might interpret it incorrectly as a server registration for an IP address(and try to route it through UDP from then onwards 😖 ).
Edit: Just looked at it's source some more... It's using 802.3 instead of Ethernet II that UniPCemu uses?

Hmmm....
Just have been comparing Dosbox-X's IPX server code (https://github.com/joncampbell123/dosbox-x/bl … e/ipxserver.cpp ) and the IPXGW code (https://github.com/jsalin/ipxgw/blob/master/ipxgw.cpp ).

So a Dosbox server registration packet has protocol 0x2(echo) and the source and destination is a NULL destination (address 00.00.00.00.00.00). Although it only checks the destination to be a NULL destination somehow (is that even correct behaviour for that hack)?
The Dosbox server answer to it is another echo packet from the connected IP address it registers to the NULL destination to the client. The client can actually repond to that, which will once again send it to the NULL destination host, because of the NULL destination source.

So basically, the NULL destination and source fields must be avoided to prevent this part of the handling from activating.

This got me thinking. Perhaps the default gateway can be used for this to be handled in a way that can be used(node FFFFFFFFFD).

Looking at Dosbox's IPX code (https://github.com/joncampbell123/dosbox-x/bl … re/ipx.cpp#L567 ), it looks like any packet broadcasted to FFFFFFFF port FFFF is receiving an ping (in this case source and destination protocol 2) back from any connected client with the source address being the client that is connected from Dosbox (https://github.com/joncampbell123/dosbox-x/bl … re/ipx.cpp#L512 ).

So perhaps UniPCemu should send a echo packet to FFFFFFFF:FFFF socket 2 from FFFFFFFF:FFFE socket 2?
Then check for any echo packets with source and destination socket echo(0x2) and destination FFFFFFF:FFFE? Then the source address would tell the server an address has been allocated.
Of course, the server itself should perform this reply to such echo requests as well to detect it's own registered addresses (as well as other UniPCemu clients that might be running on the network)?

In that way, UniPCemu should be able to check for assigned IPX addresses, trying the next address until no replies arrive within a certain timeout, in which case a free IPX address for use by the client has been found?

OK. Just made the IPX packet handling receive IPX node broadcast on the used network number. It will then respond with the same packet, but giving a directed response back to the client that requested the echo.

Now I still need to implement the filtering on the packets themselves. Then I'll need to add a proper implementation of using the echo packets for authenticating (using some timeout mechanism on the echo) newly requesting logins. When such authentication fails, it'll need to give a NAK on the PPP request packet with the next node number to try. So send an echo request, check if the echo comes back before timeout. If the echo comes back with the specified network and node number, go on and perform a NAK with the next node number specified. Otherwise, proceed to login using the specified network/node number and count the user as logged in.

Just finished the handling of the new echo method of handling the IPX packets using the information provided in this thread.

Now it sends out an IPX echo request when a client tries to login. If any client responds to it with the requested network node address as the source, it will NAK the IPXCP request with the next available IPX node number (skipping the NULL, broadcast and reserved address for the IPXCP server to receive the replies of the echo packets on (FFFFFFFF port FFFE in the Dosbox-compatible IPv4 addressing, IPX network node FFFFFFFFFFFE)).

So based on that (together with a 1.5 second timeout on the receiving of the echo replies), it should now be able to properly authenticate a IPX client every 1.5 second with full Dosbox-compatibility (although it's sending/receiving IPX packets on the ethernet II protocol instead of the 802.3 protocol).

Theoretically, it could communicate with Dosbox properly when the IPXGW program is patched to use the ethernet II type IPX framing (or support it as another alternative to the 802.3 protocol, either in parallel with it or replacing it).

Although I didn't manage to start testing the whole login and IPX server yet, since I still need to manage to get a proper MS-DOS with PPP and IPX packet driver setup working (that's in another thread, mentioned in How to emulate a dial up connection over IP? )

I've managed to at least implement the PPP side of connection and transmitting/receiving IPX packets. See my other thread (How PPP IPX works with an ISP?). As with my other conversations, I'm moving there for everything related to PPP and IPX.