davidrg wrote on 2023-09-01, 22:15:

superfury wrote on 2023-08-31, 10:40:

Although I can't seem to find a PPP IPX driver for MS-DOS anywhere. Anyone knows of any (to use with etherppp and friends)?

There are certainly IPX over PPP solutions for MS-DOS but the ones I'm aware of aren't free and I doubt they'd work with etherppp, etc. The ones I'm aware of are built to work with Novells 16bit NetWare DOS Client (IPXODI.COM, LSL.COM, etc) as that was the main reason you'd want to run IPX over PPP - to remotely connect to a NetWare server at work. Probably much easier to just run IPX over TCP/IP - this is what Novell ended up doing in the mid-90s.

Well, UniPCemu has a PPP server (when compiled with it enabled, as the server builds that are released currently are). You can connect to it using Dosbox-style dial-up. Said PPP protocol is implemented over the real ethernet (using ethernet packets using the pcap library to send/receive) or internal(when not using pcap, basically just routing the sent packets over the internal network UniPCemu provides) networks.
The PPP-based networking UniPCemu provides both IPv4 and IPX support (they can even be used simultaneously!). When networking over the real network using pcap, it's simply wrapping the packets sent with just a ethernet header to select a destination (direct or broadcast using IPv4 packets, always broadcasting using IPX packets(EtherType 0x8137, see Ethernet II encapsulation (https://en.wikipedia.org/wiki/Internetwork_Packet_Exchange))). Allocation of IPX addresses is simply done using IPX echo request and reply (if an address replies, it's assumed to be allocated). So it can theoretically communicate with Dosbox-style IPX (provided that the Dosbox server converts between the ethernet and it's own UDP-based protocols, perhaps even supporting it directly (as a passthrough).
UniPCemu itself, when using IPX over PPP, simply sends the packets to the ethernet interface as a broadcast. When receiving, it will filter to just accept broadcasts and the client's own IPX node number and network number, then send those to the connected client (routing it there).
IPv4 is simply applied to use broadcasts and directed MAC addresses (each client has one assigned from a range in the settings), using basic ARP to determine used addresses (when allocating) and filtering incoming IPv4 packets based on the MAC address (broadcast vs client itself) and IPv4 destination address (broadcast vs client itself), combining those for the correct results (filtering out packets that don't apply to the client).

One nice thing I even did was using a properly configured COM0COM driver to connect to UniPCemu's virtual Hayes-compatible modem and connect Windows 10 to said network that way (by dialing UniPCemu's PPP server just like a Dosbox client would) to get Windows 10 connected to Windows 9x clients that were connected the same way.
Multiple Windows 9x clients properly communicated to each other using both IPv4 and IPX using said PPP server. IPv4 internet access worked as well. I even played Doom95 over (MS-DOS) IPX using Windows 9x that way! 😁 You just need to connect to the PPP server as usual (although Windows 9x has a bug using IPX together with IPv4 somehow, sending invalid, corrupted, PPP IPX packets, so just disable IPv4 in that case. UniPCemu tries to handle those, but other Windows 9x clients won't properly understand those packets received if used that way. It has something to do with using IPv4 and IPX on the same PPP connection in Windows 95.). Although with Doom95, you need to select the MS-DOS IPX method and not the Windows one (the Windows one (DirectX one if I remember correctly) won't be used properly it seems, for some reason, not using the PPP connection at all).
So UniPCemu does try to implement PPP SNAP if detected (and will change IPX to use that once a packet has been received from the client using that method), but it doesn't work 100% afaik.

So it runs just fine with Windows 9x using IPX over PPP, just bare MS-DOS doesn't have proper drivers to do that.

Question for EtherDFS users. How fast are your transfer speeds? Finally I've been able to execute and develop FastDoom directly from an EtherDFS shared folder (86Box <-> PCap <-> Windows 10 <-> Ubuntu WSL EtherSRV) but transfer speed is kinda low, even if I'm emulating a fast machine (K6-II 200). It's close to 1.5Mbps, and it doesn't matter if I use an ISA NE2000 card or a PCI 8029AS as emulated network card.

Anyway, It's really great to be able to use 86Box this way, as Hercules InColor emulation is much better compared to DosBox-X. This is using Oerg866 modified source code, now it's working perfectly fine on my new machine and doesn't require a FAT emulated drive!!

EDIT: Found a card that makes everything go much faster! The PCI AMD PC-Net FAST III is the real deal, I get 15-16 Mbps transfers

ViTi95 wrote on 2023-09-28, 21:16:

EDIT: Found a card that makes everything go much faster! The PCI AMD PC-Net FAST III is the real deal, I get 15-16 Mbps transfers

which endpoint was the bottleneck?

rasz_pl wrote on 2023-09-28, 22:42:

ViTi95 wrote on 2023-09-28, 21:16:

EDIT: Found a card that makes everything go much faster! The PCI AMD PC-Net FAST III is the real deal, I get 15-16 Mbps transfers

which endpoint was the bottleneck?

The emulated network card / packet driver in 86Box. First I started with an ISA 16-bit NE2000 card (~1.4Mbps), then switched to the PCI Realtek 8029AS (~1.5Mbps) and finally to the PCI AMD PCnet Fast III.

davidrg wrote on 2023-09-01, 22:15:

superfury wrote on 2023-08-31, 10:40:

Although I can't seem to find a PPP IPX driver for MS-DOS anywhere. Anyone knows of any (to use with etherppp and friends)?

There are certainly IPX over PPP solutions for MS-DOS but the ones I'm aware of aren't free and I doubt they'd work with etherppp, etc. The ones I'm aware of are built to work with Novells 16bit NetWare DOS Client (IPXODI.COM, LSL.COM, etc) as that was the main reason you'd want to run IPX over PPP - to remotely connect to a NetWare server at work. Probably much easier to just run IPX over TCP/IP - this is what Novell ended up doing in the mid-90s.

Why has nobody in all these years tried making a free/open source IPX solution for it (like for MS-DOS Doom multiplayer etc. for example) like Dosbox's IPX server, but using PPP instead?

I mean, PPPD has been ported to MS-DOS for IPv4-only (afaik), so why don't any IPX versions exist?

Here someone claims to have fixed some bugs and made ethersrv more portable:
https://gitlab.com/mortmann/etherdfs
https://gitlab.com/mortmann/ethersrv

Seems like creating merge requests seems to be considered old-fashioned nowerdays, unfortunately.

this is a very nice program... unfortunately due to its nature... it wont work over slirp... so i can't use it (don't want to install pcap...), also i can't have a linux OS to have as server either... altought i could port the program to windows...
as i'm trying to find a x86box solution that is better than their emulated CD-ROM (That have two issues... it has to list all filenames, and will only update with a hardware restart... (takes about 1min to list my DOS folder on windows... and it's read-only obviously)

maybe i could change it a bit to work over COM... and just implement the protocol on my own on windows... but 115200 would be extra slow... so probabily a TCP/IP is the only way to have that working trough slirp... either that or use PING packets instead that seems to work trough slirp, but still it's a good project...

if it was over UDP i would have another card specifically for it... to prevent conflicts with non TSR... but it would be scare if there's TCP/IP applications out there that ignore IP and PORT... really scary!...

(and yeah i'm avoiding MS lanman this time... because of th NDIS requirement if it was simple enough to have that working trough a TCP/IP... but oh well), but if anybody have alternatives they are welcome, before i get time to try to make forks of this thing 😀

citronalco wrote on 2023-11-17, 08:36:

Here someone claims to have fixed some bugs and made ethersrv more portable: https://gitlab.com/mortmann/etherdfs https://gitlab […]
Show full quote

Here someone claims to have fixed some bugs and made ethersrv more portable:
https://gitlab.com/mortmann/etherdfs
https://gitlab.com/mortmann/ethersrv

Seems like creating merge requests seems to be considered old-fashioned nowerdays, unfortunately.

It's severely inconvenient when we're used to the comfort of PRs in github-style sites when the original *isn't* on one of those but on the archaic sourceforge 😜

The dev chooses to use what he wants to use, those who fail to use and keep apprised of different tools and instead insist on using the same for everything while peer pressuring those who don't seems "archaic" to me.

You could say it is on gitlab (which the original code is) since the author links to that repo on his site: https://ethflop.sourceforge.net/

ViTi95 wrote on 2023-09-28, 21:16:

Question for EtherDFS users. How fast are your transfer speeds? Finally I've been able to execute and develop FastDoom directly from an EtherDFS shared folder (86Box <-> PCap <-> Windows 10 <-> Ubuntu WSL EtherSRV) but transfer speed is kinda low, even if I'm emulating a fast machine (K6-II 200). It's close to 1.5Mbps, and it doesn't matter if I use an ISA NE2000 card or a PCI 8029AS as emulated network card.

Anyway, It's really great to be able to use 86Box this way, as Hercules InColor emulation is much better compared to DosBox-X. This is using Oerg866 modified source code, now it's working perfectly fine on my new machine and doesn't require a FAT emulated drive!!

EDIT: Found a card that makes everything go much faster! The PCI AMD PC-Net FAST III is the real deal, I get 15-16 Mbps transfers

How do you measure that?

I use James Pearce DISKTEST on my RetroNAS EtherDFS server and i get:

Keep in mind, i'm using a Raspberry Pi 3 model B, i have a 128GB USB 3.1 thumbdrive formatted as VFAT, but the Pi 3 has no USB 3 ports. Maybe with USB 3 i could get faster results but this isn't too bad. Right?