Shadow Lord wrote on 2024-09-20, 19:00:

Yes, please.

Seeing the massive interest in a DOS EtherDFS server (3 people, which easily accounts for some 75% of the total user base) I quickly looked into it. Not as straightforward as I thought: there is still some back-and-forth translation required between int 2Fh and int 21h calls, but nothing difficult. Just slightly boring.

For those interested, here's a teaser (ETHERSRV.EXE):
https://sourceforge.net/p/etherdfs/code/HEAD/ … rsrv-dos/trunk/

Very limited yet - a client is able to connect and perform a FindFirst() on any disk of the server. Keep looking at this location for further evolution.

mateusz.viste wrote on 2024-09-23, 15:41:

For those interested, here's a teaser (ETHERSRV.EXE):
https://sourceforge.net/p/etherdfs/code/HEAD/ … rsrv-dos/trunk/

"Teaser version" of ETHERSRV.EXE updated, same URL. Now the DOS version allows to browse/create/delete directories, read files and delete files. Should be enough to allow simple stuff (browsing a disk, copying stuff and running simple apps).

What's missing: write-to-file support, fancy open-file modes, setting attributes on files, renaming files, seeking from end of files, truncating files.

I might do a pause with this for some time, as it has eaten more time than I had budgeted already.

Feel free to test it. I guarantee nothing. If your PC explodes or aliens eat your data it's on you.

mateusz.viste wrote on 2024-09-24, 13:47:

"Teaser version" of ETHERSRV.EXE updated, same URL. Now the DOS version allows to browse/create/delete directories, read files a […]
Show full quote

mateusz.viste wrote on 2024-09-23, 15:41:

For those interested, here's a teaser (ETHERSRV.EXE):
https://sourceforge.net/p/etherdfs/code/HEAD/ … rsrv-dos/trunk/

"Teaser version" of ETHERSRV.EXE updated, same URL. Now the DOS version allows to browse/create/delete directories, read files and delete files. Should be enough to allow simple stuff (browsing a disk, copying stuff and running simple apps).

What's missing: write-to-file support, fancy open-file modes, setting attributes on files, renaming files, seeking from end of files, truncating files.

I might do a pause with this for some time, as it has eaten more time than I had budgeted already.

Feel free to test it. I guarantee nothing. If your PC explodes or aliens eat your data it's on you.

What about a Windows version?

superfury wrote on 2024-09-24, 16:49:

What about a Windows version?

Last time I used Windows was some 20 years ago, so creating an EtherDFS server for Windows is an exercise I leave to someone else. Note that it is possible to run the Linux version of ethersrv in a VM, or within the WSL2 thing provided by current versions of Windows.

Wait, do you mean Windows no longer runs DOS programs but runs Linux ones? The horror!

javispedro1 wrote on 2024-09-24, 18:32:

Wait, do you mean Windows no longer runs DOS programs but runs Linux ones? The horror!

Well if you have a 32bit version of windows you can still try. But that I believe ended sometime back with Windows 10. After that all versions have been x64.

Managed to almost get the EtherDFS PPP driver working now. The only thing that still needs fixing is the remote MAC address detection, but that's an extra feature (provided though the edfs-up.bat file (like ip-up.bat)) as well as a special ARP protocol for reporting it (using 6-byte protocol addresses will report the MAC address (like normal ARP) back to the MAC address of the sender locally on the client).

You can even connect it to itself once this final part of the feature is working properly 🤣 I already implemented that feature (using the Hayes modem RING result after ATS0=0 (to disable autoanswer mode) result of OK, it will perform ATA to answer the ringing instead of dialing out). All using a dial-up connection of course. Maybe even a direct serial connection, if the original driver allows for that. I think that the driver might support it, at least, seeing as the connect function (which dials out) can also detect just a carrier to succeed with some special settings.

Of course I'll still need to check if the packets get through after this is properly working (I'm working on fixing the EDFSCP protocol stage now).
Edit: After some debugging the various NAK/Reject behaviours, I now see the client properly handling those settings. The client can now (if instructed) accept (use the other side's MAC address for/as the remote), reject (disable the MAC address for the remote) or specify a MAC address for the remote to obtain.
You can use those two settings (specify will overrule accept/reject) to connect two of the EtherDFS PPP clients together if you want to. Even nicer is that you can use two modems, with one of the two modems dialing out (normally) and the other being in answer mode to connect two clients together that way (once the modem starts to ring) 😁

I've left the debug information that's stored in the edfs-up.bat file (although padded to 6 bytes due to the adapted MAC address function I adjusted based on the IPv4 address generation function for the file. It will receive an ipinfo field with the first byte set to the actual flags that have resulted from EDFSCP negotiation (bit 0: own MAC valid, bit 1: remote MAC valid, bit 2: EDFSCP layer up, bit 3: layer has been up at least once, bit 4: own ACK packet handled, bit 5: remote MAC ACK handled). If there's trouble with the connection, that'll help with troubleshooting.

Now comes the fun part: the actual processing of the data packets with MAC-ish headers (actually the packet's ethernet data on the PPP packet just has the MAC destination and source address, so everything from the whole ethernet frame is there. Just a bit different protocol field due to PPP protocol numbering restrictions) 🤣
Right now, looking at my packet server, it's not receiving any EDFS packets from the client for some reason, besides EtherDFS hanging for some odd reason.
Edit: After some sendparams function (that reformats the packet data for sending over the PPP connection) bugfix, I now see my UniPCemu PPP packet server (on Windows) receiving the packet and reformatting it back to what it's supposed to be on the Ethernet II network! 😁
Edit: The receiver functionality also seems to be working I think. I see the packet server receiving the packets it sends by broadcast and relaying them to the client. Although I don't know if the EtherDFS client recognises that?

OK. Went and tried something.

I took 2 instances of Dosbox 0.74 and two copies of the same floppy disk image containing MS-DOS 6.22, EDFSPPP, ethersrv and etherdfs.
And one copy of a hard disk image for MS-DOS (which I transfer files with usually, but it's a copy).

Then booted up one with the hard disk image and ran ethersrv on it, after connecting to UniPCemu's packet server using EDFSPPP.
Then booted up another instance of Dosbox with just a copy of the floppy disk image, used EDFSPPP to connect to the UniPCemu packet server as well. Both got two different MAC addresses, as is expected.
Then ran ethersrv on that Dosbox machine with just ethersrv :: c-c

CD'd to the hard disk drive (which previously wasn't there) and ran dir...

I use Wireshark just to be sure to look at what's being sent. I see packets going in both direction between the server and client's virtual MAC addresses (provided by UniPCemu's server build). Slowly, entry by entry (about 3 entries/second) the directory listing appears.
MD also seems to work properly.

DIR works. Although on long lists the server spams "FindNext failed: DTA not found in cache"?
Trying to use type on a text file gives "File not found - " followed by the filename on the client, and 5 times
"Unsupported subfunction call 0x2E, packet ignored" on the server.

So it appears that the packet driver I made is correctly doing it's job, as the two can communicate with each other.

Things go weird when I try executing anything. The server dumps 'opened file, handle=xx' followed by 'closed file, handle=xx', xx being a number, probably hexadecimal. The client side gives me 'Error in EXE file'.

Edit: Using my EDFSPPP driver with ethersrv and etherdfs programs in direct mode (using the /r command on the 'server' device in answer mode and /s on both to provide the remote a MAC address for the other client), it goes interestingly.
Both can run a server and answer requests from the client on the other side. But only the server without a hard disk (that's in answer mode if i'm not mistaken, unless it was the other way around) can for some reason be seen using the :: command on the other's etherdfs command (it dumps something like 'invalid disk' when being directory listed on)?

Tried it today between 2 Dos 7.1 pc's but unfortunately can't do much more then do dir commands. Copying files (with NC or copy command) to and from server fails with "File not found" or "Lock violation" errors on client side. Also just using the list.com program to list small text files causes a "divide overflow error" on client side.

On server side I see a lot "Unsupported subfunction call 0x21, packet ignored" and opened/closed file handle=05 messages. But I guess the last is not a problem?

Yoghoo wrote on 2024-09-25, 18:36:

Tried it today between 2 Dos 7.1 pc's but unfortunately can't do much more then do dir commands. Copying files (with NC or copy command) to and from server fails with "File not found" or "Lock violation" errors on client side. Also just using the list.com program to list small text files causes a "divide overflow error" on client side.

On server side I see a lot "Unsupported subfunction call 0x21, packet ignored" and opened/closed file handle=05 messages. But I guess the last is not a problem?

It is very much a work-in-progress thing ("teaser") and indeed - troubles are expected. I was able to perform very basic file access on SvarDOS and stopped there. I guess that MS-DOS requires a few extra calls for even simple file I/O. Subfunction 0x21 is "seek from end of file" and subfunction 0x2E is "extended open file". I will implemented these two next time I will fiddle with ethersrv - probably within a few days.

As I couldn't get ethersrv-linux to compile on my Asustor NAS because of missing dependencies (which are not in the Asustor repository) I created a statically linked executable on another Linux host.

I'll upload it here as it could be of use for somebody else as well. Should run on most x86-64 Linux systems .

mateusz.viste wrote on 2024-09-25, 19:03:

I will implemented these two next time I will fiddle with ethersrv - probably within a few days.

Just checking if you managed to make the changes? Getting the DOS version of ethersrv would be amazing. I want to mount ISO files from a network drive within DOS via SHSUCDX so I can play multiplayer games I own (like C&C) that require IPX. The problem with other network drive implementations is that they require TCP/IP. You can’t run IPX and TCP drivers at the same time without multiplayer games breaking. Accessing the ISO file on a network drive just with raw packets would be perfect. I could setup a DOSbox environment on the LAN to run ethersrv on my network to serve all my DOS machines. Very exciting.

zuldan wrote on 2025-03-09, 04:15:

Just checking if you managed to make the changes?

Not yet, no. I did the most challenging part just to prove it's perfectly achievable, and what's left is the easy-but-very-boring details. I still plan to get back to this and close it, but it's pretty far down on my list of priorities at the moment.

mateusz.viste wrote on 2025-03-10, 07:24:

zuldan wrote on 2025-03-09, 04:15:

Just checking if you managed to make the changes?

Not yet, no. I did the most challenging part just to prove it's perfectly achievable, and what's left is the easy-but-very-boring details. I still plan to get back to this and close it, but it's pretty far down on my list of priorities at the moment.

No problem at all. When you get a chance to look at this again, I’m more than happy to do some testing for you.

Thank you for making this awesome software! Can’t wait to get it all up and running on my LAN.

mateusz.viste wrote on 2025-03-10, 07:24:

zuldan wrote on 2025-03-09, 04:15:

Just checking if you managed to make the changes?

Not yet, no. I did the most challenging part just to prove it's perfectly achievable, and what's left is the easy-but-very-boring details. I still plan to get back to this and close it, but it's pretty far down on my list of priorities at the moment.

Thank you for the update. I'm also looking forward to a MS-DOS release of Ethersrv.

keenerb wrote on 2024-09-20, 21:36:

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

Perfectly fine, if you keep your ducks in a row.. See http://floppy.museum/thispc.htm - I run httpsrv, ftpserv and ircd on the same machine (a 286) using desqview. An important component is pktmux - basically it provides multiple virtual packet driver, one for each (set of) protocol(s) or TCP/IP port(s) you want to handle. Sadly, you may end up having problems running ethersrv and etherdfs on the same machine as I can't think of a way to tell pktmux how to distinguish the packets from the two.

Oerg866 wrote on 2023-08-02, 03:10:

Hello all, […]
Show full quote

Hello all,

I hacked together a quick solution for filesystem case sensitivity as well as being able to access longer filenames through their truncated names (and also make it skip spaces in the file/dir names).

@mateusz.viste you can use this as inspiration for how you wanna solve this issue. For now it seems to work for me :)

https://github.com/oerg866/ethersrv-linux-866 … 00d2d91f90afd70

Hey, I've been attempting to apply the various IFDEFs (to support FreeBSD) from https://github.com/michaelortmann/ethersrv to your port, but I'm hopelessly underqualified and there's significant divergence that I can't easily fix myself. I'm *really* keen on getting the case- and LFN-problems sorted, as needing an msdosfs filesystem kinda breaks my hope of having "one source of files for all" (long story). In my particular use-case, attributes aren't interesting.

If you were to find some time where you have nothing else to do, may I humbly ask that you take a look at the differences in code and see how hard it would be to incorporate? As for testing on FreeBSD, it's pretty simple: Install the latest release in a VM, pkg install git, git pull ...., make .. since it comes with all the compilers you'll need. Or poke me, I'd be happy to help. :)

Hi! I can check it out next week or so, please spam me with PMs until I get around to it 😁

ltning wrote on 2025-03-22, 11:42:

Oerg866 wrote on 2023-08-02, 03:10:

Hello all, […]
Show full quote

Hello all,

I hacked together a quick solution for filesystem case sensitivity as well as being able to access longer filenames through their truncated names (and also make it skip spaces in the file/dir names).

@mateusz.viste you can use this as inspiration for how you wanna solve this issue. For now it seems to work for me 😀

https://github.com/oerg866/ethersrv-linux-866 … 00d2d91f90afd70

Hey, I've been attempting to apply the various IFDEFs (to support FreeBSD) from https://github.com/michaelortmann/ethersrv to your port, but I'm hopelessly underqualified and there's significant divergence that I can't easily fix myself. I'm *really* keen on getting the case- and LFN-problems sorted, as needing an msdosfs filesystem kinda breaks my hope of having "one source of files for all" (long story). In my particular use-case, attributes aren't interesting.

If you were to find some time where you have nothing else to do, may I humbly ask that you take a look at the differences in code and see how hard it would be to incorporate? As for testing on FreeBSD, it's pretty simple: Install the latest release in a VM, pkg install git, git pull ...., make .. since it comes with all the compilers you'll need. Or poke me, I'd be happy to help. 😀

Hi, I merged in the FreeBSD stuff, can you test it pls?

Oerg866 wrote on 2025-03-24, 18:08:

Hi, I merged in the FreeBSD stuff, can you test it pls? […]
Show full quote

ltning wrote on 2025-03-22, 11:42:

Oerg866 wrote on 2023-08-02, 03:10:

Hello all, […]
Show full quote

Hello all,

I hacked together a quick solution for filesystem case sensitivity as well as being able to access longer filenames through their truncated names (and also make it skip spaces in the file/dir names).

@mateusz.viste you can use this as inspiration for how you wanna solve this issue. For now it seems to work for me :)

https://github.com/oerg866/ethersrv-linux-866 … 00d2d91f90afd70

Hey, I've been attempting to apply the various IFDEFs (to support FreeBSD) from https://github.com/michaelortmann/ethersrv to your port, but I'm hopelessly underqualified and there's significant divergence that I can't easily fix myself. I'm *really* keen on getting the case- and LFN-problems sorted, as needing an msdosfs filesystem kinda breaks my hope of having "one source of files for all" (long story). In my particular use-case, attributes aren't interesting.

If you were to find some time where you have nothing else to do, may I humbly ask that you take a look at the differences in code and see how hard it would be to incorporate? As for testing on FreeBSD, it's pretty simple: Install the latest release in a VM, pkg install git, git pull ...., make .. since it comes with all the compilers you'll need. Or poke me, I'd be happy to help. :)

Hi, I merged in the FreeBSD stuff, can you test it pls?

Brilliant! It seems to work - sharing files from a ZFS filesystem to my DOS 6.22! Thanks so much!

There are some rough edges here and there (long-to-short filename conversion would be even more compatible if it was according to fat16-lfn rules, as I got failures reading some files where the first 8 chars are the same - but that's horrible nitpicking on my part. :)

Thanks again!
/Eirik