leonardo wrote on 2022-03-16, 16:22:

Are you aware of ipxgw?

This apparently solves the problem of connecting DOSBox-clients with real DOS/Win9x systems on the LAN.
If you can make use of this solution and make the whole thing run on OpenWrt, you'll be loved by all and songs will be written about you. 😁

Thank you for this.

leonardo wrote on 2022-03-16, 16:22:

Are you aware of ipxgw?

This apparently solves the problem of connecting DOSBox-clients with real DOS/Win9x systems on the LAN.
If you can make use of this solution and make the whole thing run on OpenWrt, you'll be loved by all and songs will be written about you. 😁

I'd not seen that before! Lately I was thinking about trying to build the reverse of this - have the physical DOS machines connect to the IPXNET servers virtual IPX network. The bits to tunnel IPX over UDP are already there on the DOS side and the amount of conventional memory to do it is probably negligible. The protocol these bits speak is different from the protocol DOSBox uses of course but I've found some documentation for it which would make re-implementing the server end of the tunnel a little easier.

https://github.com/fragglet/dali

davidrg wrote on 2022-03-16, 20:14:

I'd not seen that before! Lately I was thinking about trying to build the reverse of this - have the physical DOS machines connect to the IPXNET servers virtual IPX network. The bits to tunnel IPX over UDP are already there on the DOS side and the amount of conventional memory to do it is probably negligible. The protocol these bits speak is different from the protocol DOSBox uses of course but I've found some documentation for it which would make re-implementing the server end of the tunnel a little easier.

Hmm... I guess there are many ways to approach the solution then. If I had to guess, I would say the safer option is to somehow be able to route the IPX traffic from an existing DOS/Win9x system to the DOSBox IPX-server rather than create an IPX-server client for the DOS/Win9x players - but I actually don't know. I'm not a developer.

The link above does this, dali runs on an old dos machine or vm if you want, and uses mtcp and will connect to various ipx servers/dosbox. Specifically the developer also wrote ipxbox which has all kinds of features such as pptp so you can use dialup networking with windows to get in on the ipx action from those more "modern" systems too. I have not played with it, but it also has the needed pieces to let you get internet access inside dosbox.

I have not used most of the features but I believe it also has a proxy server of sorts to allow ipx quake clients to connect to tcp quake servers etc. All kinds of cool stuff if you check out the documentation

https://github.com/fragglet/ipxbox

leonardo wrote on 2022-03-16, 21:03:

Hmm... I guess there are many ways to approach the solution then. If I had to guess, I would say the safer option is to somehow be able to route the IPX traffic from an existing DOS/Win9x system to the DOSBox IPX-server rather than create an IPX-server client for the DOS/Win9x players - but I actually don't know. I'm not a developer.

Wow, these are even better.

leonardo wrote on 2022-03-16, 21:03:

Hmm... I guess there are many ways to approach the solution then. If I had to guess, I would say the safer option is to somehow be able to route the IPX traffic from an existing DOS/Win9x system to the DOSBox IPX-server rather than create an IPX-server client for the DOS/Win9x players - but I actually don't know. I'm not a developer.

The approach I was thinking of was to use the existing IPX-over-UDP feature present in the Novell network stack most people already use to get IPX connectivity on DOS. If you use the newer 32bit version of this network stack you can shift the whole lot (LSL, network card driver, TCP/IP stack, IPX and the IPX-over-UDP tunnel) into protected mode leaving you with only 4KB of conventional memory used (and that 4KB stub will load high automatically if it can).

But the IPX-over-UDP feature depends on a server program (two actually) and the internal details of that are not public, only protocol the client uses to talk to the server. Even with the documentation I found some time with wireshark would still be required to fill in the gaps. For example, the documentation only discusses how client-server communication works, it says nothing about client-client communication (does it go via the server like how DOSBox works? Is there some mechanism clients use for converting IPX addresses to/from IP addresses allowing them to talk to each other directly?). So building something like Dali from scratch is probably easier and has the benefit of being open-source.

IPX-over-UDP (iptunnel, netware/ip) etc will be no good for gaming. They do not handle broadcast traffic, well iptunnel sends broadcast to the gateway but everything else is to an ipv4 mapped address from the ipx node address (so will never work over the internet, this is meant for a private ipv4 network), and the other netware/ip use other methods for service discovery that are not helpful for games, it can handle the client to client traffic but broadcast traffic (i.e. ipxsetup) will not make it.

I wrote a new ipx-over-udp odi driver. The only reason I did this over DALI was that I needed a full ipx/spx stack, which I use for connecting to netware servers, and I only use IPX stuff, no tcpip stack on the server.

I am not sure, it sounds like you want to re-write dali? but dali is already opensource.

yyzkevin wrote on 2022-03-17, 01:02:

IPX-over-UDP (iptunnel, netware/ip) etc will be no good for gaming. They do not handle broadcast traffic, well iptunnel sends broadcast to the gateway but everything else is to an ipv4 mapped address from the ipx node address (so will never work over the internet, this is meant for a private ipv4 network), and the other netware/ip use other methods for service discovery that are not helpful for games, it can handle the client to client traffic but broadcast traffic (i.e. ipxsetup) will not make it.

I wrote a new ipx-over-udp odi driver. The only reason I did this over DALI was that I needed a full ipx/spx stack, which I use for connecting to netware servers, and I only use IPX stuff, no tcpip stack on the server.

I am not sure, it sounds like you want to re-write dali? but dali is already opensource.

I wasn't aware of Dali until today - I just found a few DeveloperNet CDs I had absolutely no idea I had a few days ago. On one of them I found a pretty big chunk of protocol documentation for NetWare/IP and was wondering of reimplementing the NetWare/IP and DSS servers would be feasible. Also, more interestingly, there appears to be a very rough SDK for building NLMs for Client32 - something I'd been looking for for a while but could find no evidence of ever existing.

Out of curiosity, how did you go about building an ODI driver? I assume you're not using the proper ODI SDK, just implementing the specs from the ODI manuals that were freely available?

It depends on what your end goal is. For gaming, I dont think re-implementing netware/ip dss etc makes sense as it would not work, but also I am not sure why you would re-implement it, it is pretty easy to run netware in a vm?

I am not using an SDK, I just wrote it from scratch initially in C and then re-wrote it in assembly. For mine you load lsl.com then ne2000.com or whatever your network card is, then novell's tcpip.exe then my program (i call it iptunnel.exe), then ipxodi.com, then whatever shell you want etc, if it is low latency you could get away with just netx.exe , but better to use vlm.exe etc so you can use packet burst and get good transfers still over wan latency.

Again, I went through all this hastle for a very specific use case. For gaming, using dali and ipxbox is like the perfect setup really.

All the information I used was from here:
https://www.novell.com/developer/ndk/odi_lan_ … components.html

The links seem to be dead now, but they were working within the past few months so I would expect it should be easy to find the documentation again.

Yeah, I do currently run NetWare (3.2 & 4.11) under KVM so for my my current setup something like ipxbox is probably more suitable. I've got NetWare/IP setup but don't currently use it for anything and I've never actually tried running a game over it - interesting that it doesn't work. IIRC Novells documentation suggested it was supposed to be pretty invisible to IPX software but I guess they were really just targeting serious business software and games probably didn't feature in their test suite.

davidrg wrote on 2022-03-17, 02:40:

Yeah, I do currently run NetWare (3.2 & 4.11) under KVM so for my my current setup something like ipxbox is probably more suitable. I've got NetWare/IP setup but don't currently use it for anything and I've never actually tried running a game over it - interesting that it doesn't work. IIRC Novells documentation suggested it was supposed to be pretty invisible to IPX software but I guess they were really just targeting serious business software and games probably didn't feature in their test suite.

Some novell documentation specifically calls out that games such as doom would not work, or at least not without some additional workarounds. For sure it was targeted to business applications and stuff within their realm. If you play with it more and play with having the broadcast traffic forwarded to all ip sites would be interesting to hear your results.

leonardo wrote on 2022-03-16, 16:22:

Are you aware of ipxgw?

This apparently solves the problem of connecting DOSBox-clients with real DOS/Win9x systems on the LAN.
If you can make use of this solution and make the whole thing run on OpenWrt, you'll be loved by all and songs will be written about you. 😁

If only i would know how to do any of this stuff

Myg wrote on 2022-03-16, 16:17:

siljo wrote on 2022-03-16, 14:52:

This is great!

Can you make one for serial1 nullmodem too?

I will think about it.

Thank you.
I think it would be a great idea.

Is there any solution that currently works for bridging DOSBox players with DOS/Win9x-players?

ipxbox claims to be able to do this, but so far I've been unable to make any headway with it. Confusingly, there are also multiple forks:

https://github.com/fragglet/ipxbox/
https://github.com/unterwulf/ipxbox
https://github.com/liangzai951/ipxbox
https://github.com/glaso95/ipxbox
https://github.com/skadarnold/ipxbox

The furthest I got was with ipxgw running in a Ubuntu 18.04 VM with a bridged network adapter (based on the solution posted in this support thread), but sadly even it fails with the clients seeing one another, but being unable to communicate properly).

I'm sorry for the OP, perhaps this should become a separate thread - but insofar as he is also basically trying to provide the same solution as ipxbox and ipxgw, it might be useful for him to know this is something we are looking for. DOSBox can already connect multiple emulated clients together, and there are several stand-alone DOSBox IPX-servers already available - just seemingly none that are particularly easy to set up for running atop embedded hardware such as a router (why else would you want a stand-alone server, just run the server on one of your multiplayer nodes!) or bridging the IPX network in a way that allows for retro hardware to join the fight with emulated clients.

leonardo wrote on 2022-03-20, 12:11:

I'm sorry for the OP, perhaps this should become a separate thread

I don't mind, this thread was pretty quiet, its nice to see some stuff go on here 😀

Fixed a bug with DESCENT where it would send a packet with destination address:port 0.0.0.0:0.

Socket.SendTo() did not appreciate the endpoint.

Will keep this updated as I go through more games.

Still having issues with ICMP on local LANs so I dont recommend to use this to play games on LANs. Use a remote server.