Some new findings!

When using a FAT32 drive on my Linux VM, the slow speed issues are resolved. Also using a better benchmark utility now. The results:

Creation of 100MB file
NDIS2/Samba -> 5.58 MB/sec
Packet/EtherDFS -> 3.04 MB/sec

Regarding to the "File not found" issue: using a FAT32 drive does not resolve my issue with copying newly created files. However, it seems to be related to the shell I'm using (4DOS):

- After file creation, I can only use type/head to view the file, but not copy it back again - "File not found"
- If at that time I start a COMMAND shell (on top of 4DOS), I can copy the new files created in 4DOS shell just fine
- exiting COMMAND and returning to 4DOS shell and I get a "File not found" error again on the same file

Weird thing is: a file created in 4DOS, is only -viewable- in 4DOS and _not_ in COMMAND (using type, contents are empty) - but copy works only in COMMAND, after which I can view the contents of this file on my local disk successfully

Hope this makes sense 😀

EDIT: Also just lost the connection to EtherSRV again (to FAT32 drive) - drive listing empty. But no errors on server side.

Thanks for your feedback! So you use 4DOS, that's good to know -- I suppose it does something differently than command.com. So far I tested EtherDFS only on FreeDOS and MS-DOS 5.x and 6.x, while you seem to be running the Windows 95 shell. I will try to setup some lab with the Win95 shell and see what's going on.

I assume you tested it all using latest version of EtherDFS (0.7) and latest ethersrv (20170211), right?

mateusz.viste wrote:

Thanks for your feedback! So you use 4DOS, that's good to know -- I suppose it does something differently than command.com. So far I tested EtherDFS only on FreeDOS and MS-DOS 5.x and 6.x, while you seem to be running the Windows 95 shell. I will try to setup some lab with the Win95 shell and see what's going on.

I assume you tested it all using latest version of EtherDFS (0.7) and latest ethersrv (20170211), right?

I'm using 4DOS 8.00 as a replacement shell for COMMAND.COM on MS-DOS 7.10. Sorry, should have mentioned that earlier. It is not related to Win95 however. You can grab the open source version here: https://www.4dos.info/4dvers/4dos800.zip - "Free 4DOS", more info here: https://www.4dos.info/v4dos.htm#751

Yes, using EtherDFS 0.7, and ethersrv (20170211).

Hello all! Today I published a new, improved version of EtherDFS (along with its companion Linux server - ethersrv-linux). Download available, as usual, on the project's website: http://etherdfs.sourceforge.net

v0.8 [2017-03-04]: - improved self-detection to avoid loading EtherDFS twice, - added unloading support (/u), - fixed a FindF […]
Show full quote

v0.8 [2017-03-04]:
- improved self-detection to avoid loading EtherDFS twice,
- added unloading support (/u),
- fixed a FindFirst regression (fixes usage under 4DOS),
- fixed SETATTR action when using a non-FreeDOS attrib command,
- implemented the 'Seek From End' call,
- minor memory optimizations,
- makes sure the redirector API is available before installing,
- support for multiple drive mappings.

Great news! A lot of improvements, as it seems from the change logs on both EtherDFS and ethersrv. Your work is much appreciated! Especially the unload option is very welcome for me (as you know). I will be trying this new version soon, and report back the results here 😀

Finally found some time to perform some tests with this new version.

The new version works good under 4DOS now!! 😎 Thanks for the fix! No issues with creating/viewing/removing files. Unloading works like a charm (and unloading the packet driver afterwards as well)
The only small issue I ran into:
- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once - I have to run this command multiple times in a row. ethersrv throws errors: RMDIR Error: Directory not empty, which of course is correct. The same test with "DELTREE /Y *.*" on the same dataset on a local drive does remove all data in one go.

Furthermore: what about LFN support? (using DOSLFN ie) Is this on your wish list? Right now when I copy files from Linux to my FAT32 drive with some or all capitals or files that do not meet the 8.3 character criteria, ethersrv shows: ERROR: invalid handle, when trying to access the files from MS-DOS (which shows "Access denied" by itself). I have to first remove the capitals and convert the filename to 8.3. I understand that is currently not possible to create LFN files from EtherDFS, but perhaps it is possible to allow EtherDFS to access LFN files? (by stripping/ignoring LFN values on access, just like MS-DOS does when Windows is not loaded)

Tiny request: allow combining /U and /Q parameters. Can easily be worked around by using "ETHERDFS.EXE /U>NUL", but oh, well 😊

All in all this version works great. Awesome work, mateusz.

mOBSCENE wrote:

The new version works good under 4DOS now!! 8) Thanks for the fix! No issues with creating/viewing/removing files. Unloading works like a charm (and unloading the packet driver afterwards as well)

Sounds great! I'm glad it works for you.

mOBSCENE wrote:

The only small issue I ran into:
- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once

I am aware of this. In fact, this is something I already fixed a week ago, but had no time to release it formally yet (and got temporarily distracted by another retro project). If you feel courageous, you might try upgrading to latest SVN version of ethersrv (no EtherDFS change is necessary). Latest SVN version of ethersrv is here:
https://sourceforge.net/p/etherdfs/code/HEAD/ … rv-linux/trunk/ (click on "download snapshot").

mOBSCENE wrote:

Furthermore: what about LFN support? (using DOSLFN ie) Is this on your wish list?

Not really in my plans, since I do not use it myself.

mOBSCENE wrote:

Right now when I copy files from Linux to my FAT32 drive with some or all capitals or files that do not meet the 8.3 character criteria, ethersrv shows: ERROR: invalid handle, when trying to access the files from MS-DOS (which shows "Access denied" by itself).

Just a hunch: isn't this because your Linux is (wrongly) treating the file system as case-sensistive? I think there are some options that need to be passed to mount, like "iocharset" or "charset", not sure which (myself I use the "msdos" mount filesystem which works properly out of the box, but I know that vfat is trickier). Last time I tried to mount a fat drive using the vfat driver I remember Linux shouting at me "warning, this filesystem will be case-sensitive" (not exact words), this appeared in the dmesg.

mOBSCENE wrote:

I understand that is currently not possible to create LFN files from EtherDFS, but perhaps it is possible to allow EtherDFS to access LFN files? (by stripping/ignoring LFN values on access, just like MS-DOS does when Windows is not loaded)

Yes, this is definitely something that needs to be addressed. Well, the "case sensitivity" issue is, I believe, a problem of your mount configuration, but "long filename to short filename" is a feature that ethersrv would need to perform on its own. I will think about how to address that.

mOBSCENE wrote:

- after copying lots of files and directories (+-200 files, 20 dirs), and wanting to remove them again in one go using "DELTREE /Y *.*", not all data is removed at once - I have to run this command multiple times in a row.

Hello, yesterday I released a new version of ethersrv-linux that fixes tha above issue.

Hi @mateusz.viste and thanks for this great tool. I'm having a problem which I don't think is the fault of EtherDFS, but maybe I can get some insight here.

My server is a Raspberry Pi with a fresh install of Raspberry Pi OS Lite. Client is DOS 6.22. On the testbench, with the machines connected through a little 5 port hub, everything works perfectly:

[Pi server]---cat6---[hub]---cat6---[DOS client]

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It works well for TCP/IP stuff. Ideally I want my Pi in another location, also accessible by wifi. This is the setup:

[Pi server]---cat6---[Ubiquiti Amplifi router]---wifi---[TP Link nano router]---cat6---[DOS client]

When I run etherdfs on the client, it appears to find the server MAC and start up. I can navigate to my mapped drive, but can't get a directory listing (File not found).

I don't really have any understanding of network protocols. Is it possible that one or both of my wifi routers are rejecting the traffic?

Pierre32 wrote on 2021-01-15, 22:22:

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It work […]
Show full quote

But it doesn't work over wifi. I have a TP Link nano router (TL-WR802N) which I use to get my retro machines on the LAN. It works well for TCP/IP stuff. Ideally I want my Pi in another location, also accessible by wifi. This is the setup:

[Pi server]---cat6---[Ubiquiti Amplifi router]---wifi---[TP Link nano router]---cat6---[DOS client]

When I run etherdfs on the client, it appears to find the server MAC and start up. I can navigate to my mapped drive, but can't get a directory listing (File not found).

I don't really have any understanding of network protocols. Is it possible that one or both of my wifi routers are rejecting the traffic?

If by "router" you mean "something that actually performs IP routing", then EtherDFS won't work, as it requires the client and server to be on a common Ethernet segment. If, however, "router" is your term for a wifi AccessPoint, then it can work - assuming the accesspoint is in some bridge-like mode and does not try to apply any kind of firewalling of its own. That being said, I have seen wifi APs that, although configured as a supposedly "transparent" bridge, were still allowing only IP traffic to pass, EDF5 frames were dropped (this was the case, IIRC, with my TP-Link RE350 AP). It is possible you have hardware that misbehaves in a similar way - in such case, all you could do is try fiddling with AP's settings to figure out how to make it a true bridge. Or use another AP.

Perfect answer, thank you. Sounds like I may be right to suspect the TP Link, so I'll explore options there. It also wouldn't be the end of the world just to move my Pi to where the retro gear is.

That's a really useful tool! Any chance of getting a Docker package? I'd like to use it on my NAS.

Reviving this thread .. @mateusz.viste I've been trying (with my extremely limited ability) to port your code to FreeBSD - but there are some references to AF_PACKET and similar Linux-isms I'm not sure how to handle. Would you be inclined to give it a go? :) Raw ethernet packets isn't a problem on FreeBSD, but since it's not IP I guess the interfaces are slightly different.

/Eirik

ltning wrote on 2022-01-10, 14:39:

@mateusz.viste I've been trying (with my extremely limited ability) to port your code to FreeBSD - but there are some references to AF_PACKET and similar Linux-isms I'm not sure how to handle. Would you be inclined to give it a go? :) Raw ethernet packets isn't a problem on FreeBSD, but since it's not IP I guess the interfaces are slightly different.

Hello Eirik, I'm sorry but I do not use FreeBSD, so such ethersrv-in-FreeBSD version would be completely useless to me. That being said, such port should be relatively straight-forward, since the only Linux-specific part is receiving and sending Ethernet frames. Replacing these routines with whatever is used by FreeBSD to send/receive raw Ethernet frames should be enough to make it work...
Or, alternatively, use a small Linux VM in your FreeBSD setup. ;-) Good luck.

Hi mateusz.viste!

Any chance EtherDFS can work in the future mapping USB drives on a router? Allow me to explain:

My connection is [ISP router] ---cat 6--- [ASUS RT-AC87U router (in AP mode)] --- cat 5e --- [DOS and WIndows PC's]

So my ASUS router which i am using as an AP (my ISP router WiFi coverage is garbage) has a nice feature that allows to connect a USB external drive to use for FTP disk access or "Network Place(Samba) Share / Cloud Disk". Using mTCP and the FTP client, i can access and retrieve files from the AP USB Disk just fine. But having to connect to FTP every time kinda sucks. It would be extremely cool (and a game changer) if EtherDFS could map as a drive letter the USB disk on an Access Point configured router as a DOS drive, just like it does with your EtherSRV tool.

Main advantage would be no need to set up a Linux NAS machine, most modern routers have this USB disk feature, so it would be nice to use it. MS Client and LAN manager just complicate things to much and take way too much memory to be practical. It would be so nice to just be able to map the drive on the router, without any need for other servers.

Just for fun, i tried running EtherDFS on my DOS PC and try to connect to my ASUS AP. So i did the usual of typing the exact MAC address of my router:

1etherdfs (AP MAC address) C-Z

I was expecting an error or something but EtherDFS actually reported:

1EtherDFS v0.8.2 installed (local MAC DOS NIC MAC address, pktdrvr at INT 60)
2Z: -> [C:] on ASUS AP MAC address

So EtherDFS actually reports the correct MAC addresses for both my NIC and my AP and tries to map C: on the AP to the Z: drive on DOS. Of course, if i try to actually access Z: i get an invalid path "Z:", because i'm almost sure EtherDFS can't actually map the "Network Place(Samba) Share" USB drive. This would definitely be a game changer. Any chance that this can be implemented in the future? Almost everyone with a modern router could use this.

Why no EtherSVR port to Windows? How hard would it be?

carlostex wrote on 2022-03-05, 13:03:

Any chance that this can be implemented in the future? Almost everyone with a modern router could use this.

EtherDFS only speaks the EtherDFS protocol. Samba only speaks the SMB protocol.

For EtherDFS to talk to Samba it would have to also implement the SMB protocol which would require a TCP/IP stack and a pile of other stuff. It would be a pretty massive undertaking and probably end up using a similar amount of conventional memory to the Microsoft client unless you put even more effort like Novell did (their client uses about as much conventional memory as EtherDFS).

It's unlikely that any manufacturer of a router or NAS is going to include a proprietary protocol like EtherDFS, even if it is open source. It's just too much of a headache for them to support in the long run.

NFS, SMB, and FTP are all well established standards. I'd look more to that "Swiss Army Knife" type project that includes SMB, FTP, EtherDFS, and other retro-friendly services like the HTTPS proxy instead. (The name escapes me but it was announced on Vogons a few weeks ago. )

RetroNAS: https://github.com/danmons/retronas/

I don't anything about protocols, so i was merely suggesting that because there would be no need for an extra machine since routers already have a USB disk. Not a big deal.