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?

I have recently made a server implementation for ETHFLOP, the little sister of EtherDFS. Keenerb suggested a similar port for EtherDFS. While at first I rejected the idea as I am not using etherdfs much myself these days, on the afterthought I might actually give it a try, if only for a laugh. I think it might turn out to be an easy and pleasant job - much easier actually than the Linux EtherDFS server, because on a DOS platform I could relay client queries as-is to the DOS kernel, without any emulation layer and ugly file-mapping.

Anyway -- is there any community interest in such EtherDFS-server-for-DOS thing?

Yes, please.

Etherdfs is still the most convenient way to get files around on the network. Every single MSDOS machine I have maps a drive to the same etherdfs share. Doing that with ethflop is much less convenient...

Could EtherDFS be mapped onto a PPP stream (maybe using a NCP protocol)? And then a driver that uses PPP to send/receive the frames? I can modify my PPP dial-up server to accept that packet type and send/receive it over to the Ethernet frames?
Would any kind of configuration (NCP configuration options) be required for that?

I think it might need a MAC address NCP option, or is it not required for the client?
So perhaps only 1 (optional) type 1 option named MAC address, length >=6 to learn the MAC address of the client? If specified anything other than the client, it will be mandatory to give the MAC address of the used (virtual) network card, NACKing it back to the host? So that way, the host can learn it's MAC address. If not specified, the connection will work, but the client won't know it's own MAC address, if it needs to.
Usual MAC address filtering applies ofc.

Should be easy enough to implement based on IPCP I think.

IDK about making a PPP driver based off that information, though? Would that be easy to adapt from (using) an existing PPP driver backend, like lsppp, dospppd etc.?

mateusz.viste wrote on 2024-09-20, 18:45:

Anyway -- is there any community interest in such EtherDFS-server-for-DOS thing?

OMG YES PLEASE!!

EDIT: With time i could try maybe later port it to Windows, i have now some experience with C# / .NET, and i could try maybe something simple like a little Windows Forms app, provided that i actually understand the protocol and manage to make it work.

How well does desqview handle packer drivers? Now I want to set up an ethflop and etherdfs desqview instance...

I'd prefer a EtherDFS-server for OpenWRT, that would be really awesome! I use an old ADSL modem as a low power WiFi-Ethernet bridge + FTP server (USB storage), this way I could have a better dev/testing environment.

Hmmm... Couldn't find a packet driver source of dospppd, but lsppp has source code?
http://macall.net/ladsoft/index.htm

Perhaps it can be adapted for providing EtherDFS over PPP?
If it can do that, maybe the EtherDFS driver call call it? Does it support a generic interface driver like IPv4 can?

Thinking about it, it would have EDFSCP protocol (with 1 optional configuration option to learn the Mac address of the client (or server in the other direction)) 8FD5h and the protocol data (like IPv4) on protocol number 0FD5. Luckily it already satisfies the PPP specifications for that, so it'd be easy to adapt that way?

It's an ethernet level driver anyways, so lsppp could be adapted to support that protocol?

Edit: Went ahead and adjusted the code to use the EtherDFS protocol instead.
* The link has been moved to my new vogons thread for it: PPP EtherDFS driver *

Some other changes I made are:
- Disable encryption, as it's unsupported on EtherDFS (IPv4 encryption that is).
- Client MAC address is reported as obtained from the EDFSCP negotiation, if available (by EDFS negotiation using EDFSCP, which is protocol 8DF5h).
- ARP using the 6-byte EtherDFS protocol reports the PPP remote negotiated MAC address, if available.
- EDFS ethernet packets sent/received on the PPP EDFS protocol number (using PPP protocol DF5h).
- Added support for the address option (option 1) to be the assigned MAC address of the receiver that's requesting the option (in a configure-request packet).
- Renamed environment name, help message and logging file to all use 'edfsppp' instead of 'lsppp'.

So that practically fixes anything needed for the EtherDFS to work when connecting to the packet driver, which handles all those cases using the interrupt handler (also reporting the negotiated MAC address learned). And EDFS ARP is for resolving the MAC address of the host on the other side, if available after negotiation.

Also, for some reason, the Makefile has a vertical bar character on it's last line?

I didn't test out if it compiles though.
Edit: Hmmm... Would it be required to prepend the destination MAC address to the packet before sending it? So it can connect to a specific MAC of a server instead of just to broadcast the packet?

ViTi95 wrote on 2024-09-20, 22:04:

I'd prefer a EtherDFS-server for OpenWRT, that would be really awesome! I use an old ADSL modem as a low power WiFi-Ethernet bridge + FTP server (USB storage)

AFAIK OpenWrt is just Linux, and apparently it has some writable space to install extra stuff. So all you need is to crosscompile ethersrv. Should be trivial, no development needed. Not something I will do, however, as I am not an openwrt user.

superfury wrote on 2024-09-20, 21:03:

Could EtherDFS be mapped onto a PPP stream (maybe using a NCP protocol)?

I have honestly no idea what this is all about. I guess it would be for some long distance EtherDFS communication ? I never used PPP. Never had a modem, actually - internet was way too expensive in my country when modems were a thing, and I did not have a phone line anyway.
For over-internet communication it would probably be easier to just add an IP header to EtherDFS frames. The protocol has a provision for this. Or encapsulate EtherDFS frames into a L2 tunnel that would connect two LANs together - it is easier, no etherdfs code change needed, but an extra device would be needed on the client side to act as an EtherDFS-to-internet bridge.

I'm now looking at my current version of EDFS if I can somehow prepend the packets with source and destination MAC address when sending (and decoding it when receiving).
That way it can fully use EtherDFS for connecting to various servers using different MAC addresses.
Although in that way, the only thing not sent over the PPP connection is actually a real Ethernet frame, since all other fields would be transmitted (with EDFS Ethertype being forced for the sent packets, no others allowed).

Edit: By handling the insertmacheader (for receiving packets) and sendparams (for sending packets) I've modified it to send the destination (first) and source (second) followed by the packet data (the EtherDFS packet) in both directions.
Essentially, it's sending and receiving full ethernet packets right now, except it's locked down to doing that for EtherDFS packets only (as it's hardlocked to the EtherDFS PPP and Ethernet type and not allowing other types of packets to be sent/received in this driver with the current setup).
The destination and source bytes are taken from the packet data, or put into the packet data when sending/receiving them (in the two functions mentioned above). The normal receive/sending handling handles their endpoints (PPP for sending or buffers/application for receiving) respectively.
I don't know if the output buffer is large enough for 12 extra bytes, though?
Edit: OK. Looked again. It has 14 extra bytes for a possible ethernet header. So no chance of buffer overflow there.

Although the whole thing I made is still untested, it should work in theory. And probably compile as well (assuming I didn't make any typos).
Edit: OK. It didn't compile at first. Needed to iron out some small issues I made in my edits (restoring DNS stuff (still unused because it was zeroed) and a label I removed because of removing encryption support caused said module to fail at other places (restored by placing back the label).

It's comiling now at least (using Make from Turbo C 2.01 with GUI Turbo Assembler 5.1 to compile it (it uses Dosbox for running it))! I also need to delete/rename BUILDINS.MAK within the BIN folder of the app, since make.exe keeps misinterpreting it (and the app recreates it on each time it's started somehow, maybe because it thinks the app is damaged because of the missing file). 😁 Simply running the generated executable makes it seem to run fine, although I don't know how it'll go wrt EDFSCP, since I haven't implemented that one yet in my own emulator. But at least the base executable to connect to a PPP server serving the protocol is implemented now.
Edit: Just implemented the EDFS protocol with that single option into UniPCemu's packet server.
So using that to connect to, it should work, in theory at least (didn't verify it yet).
Edit: OK. Managed to get it to start negotiating the EDFSCP protocol after adjusting the PPP protocol field to 8EF5h and packet channel to EF5h (these were causing issues with protocol field compression, due to the high byte being odd, which needed to be even).
Now the driver seems to send only a 4-byte address field, while it should send a 6-byte address field.
Edit: Fixed the detection of the EDFSCP protocol being up or down, together with having remote and/or local MAC addresses detected correctly (as reported by running EtherDFS).
The only strange thing is that after mounting a disk using EtherDFS, I don't see any packet being sent by the driver over the serial connection?
Edit: Fixed an issue with the packet driver. The stack wasn't cleaned up properly after checking for the special EDFS packet functionality. It should work now, probably.
Edit: Hmmm... Even with those bugfixes, it still crashes somehow?
Running etherdfs 12:34:56:78:9a:bc c-x succeeds in both cases (with esdfsppp correctly listing the local mac when EtherDFS is ran). But with EtherDFS, the whole thing hangs immediately?
Does EtherDFS require a response to work properly? Why won't my modified packet driver send the packets it's supposed to send on to the PPP connection?
Edit: Hmmm... It looks like I've somehow broken the lsppp app with my changes somehow? Can anyone see what's going on?
I run it connecting lsppp or edfspppp to UniPCemu in the same way (with CHAP authentication). I know that the invalid packet types are being blocked by the driver, so that's working properly.
It seems that when the driver tries to send data it somehow goes wrong and ends up hanging the driver? lsppp's original code makes it continue on fine when that happens from what I can see?
Edit: Fixed some bugs in my adjusted code in the EtherDFS PPP driver.
It seems to run now, without crashing at least. The main issues were:
- Moving data back in the source buffer for parsing the extra EDFS packet headers in the data portion of the Ethernet frame (moving the headers sent by the packet server into the received MAC fields expected) to properly save and restore ES for the REP MOVSB instruction to move the data block (instead of using a different ES segment).
- When the EDFSCP layer comes up, properly call vjinit again to initialize the required subsystem (even though it isn't made active due to the define disabling encryption).
(and after that fix the invalid DNS flag I accidentally restored in that commit, which isn't used anymore with the new EDFSCP protocol).

Although the ipup.bat file still reports only the first 4 bytes of the MAC addresses (of the client and server(if provided in the packet server settings)) instead of all 6 bytes of the MAC address.
But luckily, the normal drivers can request those two fields in binary format using the normal driver interface(for the client MAC address, if obtained from the EDFSCP negotiation) or using the special ARP handling (which will result in the server reporting the MAC address results for the EDFS protocol type of any request with the MAC address of the server. This ARP response will only happen if the connecting server identifies itself with it's MAC address (in the documented ARP reply packet way, but with 6 byte protocol addresses instead of IPv4's normal 4 byte protocol addresses) during negotiation (if it isn't provided, ARP EDFS protcol responses are disabled)).
Maybe I'll fix that one later, but for now the driver runs properly from what I can see. Didn't test it actually sending EDFS packets to the server, though. It should send them, according from what I understand from the source code.
Edit: Hmmm... epb_send_pkt in PKT.ASM is for sending a packet for a driver. it calls interfaceup(carry returned for down) to check if the interface is up. Then it makes DS:SI point to the buffer by the app and CX to the amount of bytes in the packet. It calls sendparams to queue it for sending (if it can) and then calls StartXmit to transmit the packet if needed (if sendparams didn't set the carry flag). Othewise, it reports it can't send the packet to the calling application.
I modified bootp_handler not to intercept, so it should progress to vjcompress. vjcompress also clears carry and returns always in my modification. It should reach startXmit(PPP.asm) if it's called.
Edit: OK. Just double-checked the EtherDFS source code. It should be using the normal interfaces (AX=201h for init, 6xx for getaddr, 3xx for free and 4xx for sending). It's init call should register a receive handler (currently nothing is received?), while the send function should be handled by the driver afaik. And if init fails, it would report it. So it should be calling the function?
Edit: Also added a bit of extra functionality. I've extended the 'IP addresses' to 6 numbers for full MAC address coverage. Then added two more options: give the remote a MAC address (assign it one) or (if not given) take their MAC address (otherwise, disable and reject it). Those two options can disable the other side from taking an address (saying it has none) or give it an address as specified. That way, it can even link up to another instance of itself. If the remote doesn't have a MAC address (by not giving it one), the remote address functionality (using ARP) is also disabled, just as if the remote didn't request itself an address.
The generated file with the local and remote addresses isn't adjusted yet, though.
Edit: That's adjusted as well now. It now logs 6 digit addresses (although still in IP dot-seperated decimal format).
Edit: Started implementing an answer dialing mode, but it's crashing right now.
Edit: Fixed the answer mode. Also fixed no-authentication mode and logging without addresses available (due to being rejected or not provided by the server).
Edit: Hmmm... After a lot of bugfixing and improvements, all seems to be working, except the EFDSCP layer going up? For some weird reason, it never reaches the opened state, despite negotiation of configure-request and configure-ack in both directions? Double checked the EDFSCP layer (IPCP.ASM) with the LCP layer and it seems to match.
Edit: OK. The issue is in the main function that checks for the used protocol (EDFSCP or IPCP in the original code) if it's ready to receive.
Oddly enough, changing it to wait for the EDFSCP layer to come up will make the driver not respond to the requests from the server or other client?
Edit: OK. This is getting way too long. I'm moving this to another thread: PPP EtherDFS driver.