VOGONS


EtherDFS - a network drive for DOS

Topic actions

First post, by mateusz.viste

User metadata
Rank Member
Rank
Member

Hi all,

I write this short announcement to present an alpha version of a new software I have been creating these past weeks. EtherDFS is an "installable filesystem" for DOS. It installs a network drive that is seen like any "normal" drive to DOS and its application, with the exception that the actual data is located on a server. The server part is called EtherSRV and currently only a Linux version of it exists. EtherDFS uses raw ethernet frames to communicate with EtherSRV - this means only a working packet driver is required, nothing else.

More information on the project's homepage: http://etherdfs.sourceforge.net

I cannot stress enough the fact that this is an alpha version - it's in a very early stage, and lots is to be done yet. It does work however, and seems stable enough so it shouldn't make your PC explode. Its memory footprint is quite huge for now, since its resident size is of 16 KiB. Future versions will surely improve on that. Also, it *should* work with MSDOS 5+, but I tested it only with FreeDOS so far.

Reply 1 of 109, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
mateusz.viste wrote:

It installs a network drive that is seen like any "normal" drive to DOS and its application, with the exception that the actual data is located on a server.

You are aware that there was a DOS version of the old Microsoft Network Client that worked much the same way, right?

Nonetheless, that setup had a tendency to consume a lot of memory and trying to get modern Windows network shares to cooperate with older clients is often an excruciating exercise, so this would be most welcome.

Reply 2 of 109, by M-HT

User metadata
Rank Newbie
Rank
Newbie
Jorpho wrote:
mateusz.viste wrote:

It installs a network drive that is seen like any "normal" drive to DOS and its application, with the exception that the actual data is located on a server.

You are aware that there was a DOS version of the old Microsoft Network Client that worked much the same way, right?

Nonetheless, that setup had a tendency to consume a lot of memory and trying to get modern Windows network shares to cooperate with older clients is often an excruciating exercise, so this would be most welcome.

I don't have a problem connecting from DOS to Linux, but you're right about the memory consumption - more than 16 KiB.

Reply 3 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member

Hello all, I released EtherDFS v0.6 a few minutes ago. This updated version brings a few bug fixes, and also heavy memory optimizations. EtherDFS' resident footprint is now only 7K (was: 16K). I tested it extensively, and it appears to be unexpectedly stable. Enjoy!

http://etherdfs.sourceforge.net

Reply 4 of 109, by mOBSCENE

User metadata
Rank Newbie
Rank
Newbie

This is an awesome project! Hoping to replace my MS-DOS networking setup to Samba on my Linux server, with this little nifty tool 😀

Unfortunately, it does not work as intended on my system: EtherDFS DOS does not recognize my server automatically, and when I manually enter the interface address in the client, it returns that it is connected to interface 00:00:00:00:00:00. The result is the drive is not being mapped. The exact messages can be found in below screenshot.

Is there something I am missing here?

wIzGwnk.png

EDIT: The output of EtherDFS server:

root@backup:/home/peter/ethersrv-linux-20170207# ./ethersrv-linux eth0 /storage/oldshit
WARNING: the path doesn't seem to be stored on a FAT filesystem! DOS attributes won't be supported.

Listening on 'eth0' [72:CD:04:1B:CF:1F]
Drive C: mapped under /storage/oldshit

Reply 5 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member

Hello mOBSCENE, thanks for reporting the issues!

In fact, I see as many as 3 problems here:
1. etherdfs doesn't see ethersrv
2. DOS doesn't see drive E:
3. manual MAC is not understood

Problem 3 seems to be a parsing regression. I will fix that soon, should be easy. However, it is unlikely to help you - if autodetection doesn't work, I don't think the rest of communication will work anyway.

Problem 2: you use MS-DOS, right? Then this symptom is normal. v0.6 doesn't expose the mapped drive in a way that is compatible with MS-DOS. It works on FreeDOS only. I have already fixed this in trunk version, so next release will be compatible with both FreeDOS and MS-DOS. Of course this has nothing to do with your communication problem.

1. This is the most serious problem, and I have no clue why it happens. Is your DOS PC able to communicate with the Linux machine through other means? If yes, could you tell me what are the IP addresses and masks of both computers? Are you positive that they both belong to the same broadcast domain (same LAN, both connected to same switch)? Are you using the latest versions of both EtherDFS and ethersrv-linux? Is your DOS system on some kind of virtual machine?

Reply 6 of 109, by mOBSCENE

User metadata
Rank Newbie
Rank
Newbie

Thanks for the quick response!

Yes, I am using MS-DOS (v7.10) indeed. Sorry, I was expecting it to work with MS-DOS already. But nice to hear that it will be MS-DOS compatible soon! I was testing this using the latest versions of both EtherDFS and ethersrv-linux.

As for the more serious problem: it seems my issue is with the packet driver. While the packet driver does seem to detect my network adapter and install the driver properly (see screenshot), I can not get the mTCP utilities to work with it. Whenever I try to set an IP address (using provided DHCP.EXE) my computer just freezes (sometimes I get one timeout message before it freezes). Also no DHCP request in my router logs. When I manually setup an IP address in the mTCP config file, and try to ping my router (using provided PING.EXE), it mentions it is unable to receive an ARP response. With the MS-DOS networking utilities (from Microsoft), I have no issues with IP setup using it's DHCP client, so I'm assuming the packet driver does not work correctly on my hardware.

I've just tried using two other (older) packet drivers, but they are not able to find my network adapter at all, and suggest to set an "id_port" parameter manually (default = 0x110). But I have no idea what data I should use here. Do you happen to have any idea? Here's me hoping the issue is with mTCP only, and your next MS-DOS compatible version will work out-of-the-box 😜

The setup of my network is quite straight forward: MS-DOS PC (real hardware) uses IP 192.168.1.140 netmask 255.255.255.0, Linux server (Debian, which is a VM) uses IP 192.168.1.175 on the same subnet. Both connected to the same router. The network adapter in my DOS machine is a 3C905 PCI adapter.

Reply 7 of 109, by mbbrutman

User metadata
Rank Member
Rank
Member

I would not hold your breath hoping that this is an mTCP only problem. mTCP works on just about everything.

Are you using the latest version? Have you tried listening for packets using PKTTOOL?

If you are not seeing incoming packets you have a cabling problem or the IRQ is wrong on your packet driver.

Reply 9 of 109, by mOBSCENE

User metadata
Rank Newbie
Rank
Newbie
mbbrutman wrote:

I would not hold your breath hoping that this is an mTCP only problem. mTCP works on just about everything.

Are you using the latest version? Have you tried listening for packets using PKTTOOL?

If you are not seeing incoming packets you have a cabling problem or the IRQ is wrong on your packet driver.

Just realized you are actually the developer of mTCP 😀 Nice of you to reply here!

I am using the latest version of mTCP (2015-07-05). It seems that whenever there's an incoming packet, my computer freezes. Also, all outgoing packets are only counting towards the "Sending errors" (when I use PING.EXE to an unavailable IP address), when viewing the stats with PKTTOOL.EXE. All other counters remain at 0.
IRQ on packet driver is correct (confirmed by 3Com setup, which also passes all diagnostic tests). And since I have zero issues transmitting/receiving packets using the TCP tools from Microsoft, it must be an issue with the packet driver on my end (perhaps related to shared memory, I don't know). Tried a clean boot (no other drivers loaded), different INT setup's for the packet driver, but all with the same result. The mTCP debug log shows parts of a packet being received at the end of the logfile, just before my computer freezes completely.

Since I'm kind of desperate to get this working, I am going to try some other NIC's (just ordered an Intel PRO/1000 GT and an Intel PRO/100B from eBay).

As for EtherDFS: my main feature request would be an option to unload EtherDFS from memory. For the purpose of enabling/disabling network access completely, without requiring a reboot. This way we can continue to play our conventional memory hungry games directly. That would really be great 😀

Reply 10 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member

Today I released EtherDFS v0.7. Few bugfixes, some optimization, and - some of you were waiting for that - MS-DOS compatibility! (tested with MS-DOS 5.0 and 6.20)
Again, please don't consider this production-ready as long as the version string doesn't say at least "1.0". Nonetheless, it works, and I hope it will be as useful to you as it is to me.

mOBSCENE wrote:

my main feature request would be an option to unload EtherDFS from memory.

That's unlikely to happen in any near future, simply because a) it's not trivial and b) I don't need it myself. Note, that EtherDFS consumes only 7K of memory - that's probably less than what your packet driver takes. And it can be loaded high, too, using loadhigh.

Reply 12 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member
luckybob wrote:

What are the chances of a windows server?

None, I'm afraid. I do not do Windows. It should be possible, however, to run ethersrv-linux as a virtual machine on a Windows host. Anyway, ethersrv is rather meant to be installed on some stand-alone NAS-like machine featuring a Linux OS - Raspberry Pi, NUC, BeagleBoard or similar. I might do a DOS version of the server at some point.

That being said, should anybody wish to start his own "ethersrv-windows" project in the future, I'd be more than happy to assist. The EtherDFS protocol that I designed is very simple, and I tried to document it extensively.

Reply 13 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member
mOBSCENE wrote:

it seems my issue is with the packet driver.

I think either something is very wrong with your hardware or low-level setup (IRQs or so), or perhaps the virtualization layer behind your Linux server does not forward EtherDFS queries to your Linux guest... or perhaps there's some kind of firewall, either on your Linux guest or on your Windows host that drops EtherDFS frames.

I assume that your main host machine is a windows PC - do you have the possibility to perform a capture of the traffic it sees, through Wireshark? This would tell us whether your DOS PC sends anything at all - and if it does, whether the server side answers anything. Another interesting test could be to setup an additional (hardware) Linux box and see if the symptoms are still the same on real hardware.

Reply 14 of 109, by mbbrutman

User metadata
Rank Member
Rank
Member
mOBSCENE wrote:
Just realized you are actually the developer of mTCP :-) Nice of you to reply here! […]
Show full quote

Just realized you are actually the developer of mTCP 😀 Nice of you to reply here!

I am using the latest version of mTCP (2015-07-05). It seems that whenever there's an incoming packet, my computer freezes. Also, all outgoing packets are only counting towards the "Sending errors" (when I use PING.EXE to an unavailable IP address), when viewing the stats with PKTTOOL.EXE. All other counters remain at 0.
IRQ on packet driver is correct (confirmed by 3Com setup, which also passes all diagnostic tests). And since I have zero issues transmitting/receiving packets using the TCP tools from Microsoft, it must be an issue with the packet driver on my end (perhaps related to shared memory, I don't know). Tried a clean boot (no other drivers loaded), different INT setup's for the packet driver, but all with the same result. The mTCP debug log shows parts of a packet being received at the end of the logfile, just before my computer freezes completely.

Since I'm kind of desperate to get this working, I am going to try some other NIC's (just ordered an Intel PRO/1000 GT and an Intel PRO/100B from eBay).

As for EtherDFS: my main feature request would be an option to unload EtherDFS from memory. For the purpose of enabling/disabling network access completely, without requiring a reboot. This way we can continue to play our conventional memory hungry games directly. That would really be great 😀

I rarely get bug reports so I have to go looking for them. 😀

It's good that the Microsoft tools work; that indicates that the hardware and cabling are good. So then the packet driver or mTCP are at fault. You can try one of the WATTCP utilities to see if the behavior is any different. If a WATTCP based program and mTCP both fail then you know where the problem is.

There are four possible things to consider when loading the packet driver. The hardware interrupt, I/O ports, and the memory window (if used) have to match the hardware exactly. If the hardware interrupt is wrong you won't get incoming packets. If the I/O ports are wrong then you probably don't even get the correct MAC address reported when you load the driver. And if a memory window is used it has to be be correct or your data will be garbled.

The fourth item is the software interrupt - that's the handler that the packet driver installs for mTCP or other applications to use.

None of these can have conflicts. If you share an IRQ on an ISA system you will get spurious interrupts or the wrong interrupt handler will be processing your network card interrupts. It's not supported unless you know for certain that the other piece of hardware is not generating interrupts and there is no installed interrupt handler for that interrupt yet. PCI is different; sharing is allowed, but I have no idea how that works in a DOS environment, so just make sure it is unique.

I/O ports and memory windows ... basically the same problem. You can't deal with conflicts. The hardware will not work.

The software interrupt just has to be one that is not already in use. You can use debug.com to examine them and see what is already in use or not. Experimenting with random ones between 0x60 and 0x7F is generally; they are not used too often so try 0x61 or 0x62. Software interrupts are first come, first served for assignment so on a cleanly booted system with few device drivers or TSRs they should all be available.

I've used mTCP to debug bad hardware before. It happens. Given that your hardware works with the Microsoft utils you should snoop around their settings to see what IRQ, I/O ports and memory window they use. Also, your packet driver executable might be borked; try a version from another driver disk/Zip file.

Reply 15 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member
mOBSCENE wrote:

Linux server (Debian, which is a VM)

Hello again - I discovered today a weird behaviour of VirtualBox when it is bridged with a WLAN adapter - shortly said, it cannot work with EtherDFS in such setup, because it knows how to handle only IP packets. Source: https://www.virtualbox.org/manual/ch06.html#network_bridged

Are you, by any chance, using VirtualBox? And if so, is your guest VM configured in 'bridged' mode with your WiFi card? If yes, then I'd suggest trying if things work better when bridged with your Ethernet (cable) interface.

mOBSCENE wrote:

my main feature request would be an option to unload EtherDFS from memory.

I re-thought about this, and I will actually do it. It's not necessarily a very useful feature in my opinion, but might make testing more convenient, and it won't increase the resident size of the TSR, so it could be nice. Stay tuned!

Reply 16 of 109, by mOBSCENE

User metadata
Rank Newbie
Rank
Newbie
mbbrutman wrote:

You can try one of the WATTCP utilities to see if the behavior is any different. If a WATTCP based program and mTCP both fail then you know where the problem is.

After the latest update of EtherDFS, with MS-DOS compatibility, my computer also froze when connecting EtherDFS to EtherSRV. So it's good to know the issue is not with mTCP 😀 Packet driver on 0x60, 0x61, 0x62 and others made no difference. I really don't know what was going on there... but thanks for thinking along!

Guess we will never know, because I have just replaced my 3C905 network card with an Intel PRO/100B and BOOM! everything works! Packet driver (on 0x60), mTCP, EtherDFS... even got it to work with the DOS NDIS2 driver easily (for accessing SAMBA shares from MS-DOS). Oh and in Win98SE it works well too.

mateusz.viste wrote:

I re-thought about this, and I will actually do it. It's not necessarily a very useful feature in my opinion, but might make testing more convenient, and it won't increase the resident size of the TSR, so it could be nice. Stay tuned!

Awesome! For me it is very useful. The packet driver can not be unloaded after loading EtherDFS, so that costs me about 20K conv memory in total (not using UMB, because it causes issues with some games, and I strive towards maximum compatibility). Yes, I am assuming that the packet driver can be unloaded, after EtherDFS is unloaded. (we'll see 😀)

Some more feedback on my experience with EtherDFS:

- EtherDFS detects my EtherSRV on my Linux VM automatically (using :: for the MAC address) - great! (running Proxmox/KVM btw, not VirtualBox)
- I can confirm it loads properly on MS-DOS v7.10 - I can access the mapped network drive just fine
- I can successfully list and create files on the network drive, but reading or removing files (old existing or new files) throws an error "File not found". But perhaps this is related to DOS attributes not working, since I'm not using a FAT filesystem on my Linux server. No errors on my server, besides the "Failed to fetch attributes of..." errors.

Keep up the great work! Both of you 😉

Reply 17 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member
mOBSCENE wrote:

I can successfully list and create files on the network drive, but reading or removing files (old existing or new files) throws an error "File not found".

Are you 100% positive that this happens also with new files (that is, files you copied through EtherDFS)? Pre-existing files won't work if they are not all-uppercase. The problem is that DOS doesn't expect the filesystem to be case sensitive, and becomes highly confused when FILE.TXT exists but FILE.txt does not.
For this reason I am wondering about making the FAT storage a hard requirement (ethersrv would refuse to start on anything else).

Reply 18 of 109, by mOBSCENE

User metadata
Rank Newbie
Rank
Newbie
mateusz.viste wrote:

Are you 100% positive that this happens also with new files (that is, files you copied through EtherDFS)?.

Just did some more tests:
- I can actually read existing and newly created files, but removing newly created files does not work (even though they are created on the server with all uppercase) - error "File not found"
- during testing the connection to EtherSRV got dropped (drive listing empty) but I can not recall what action caused it (just copying files over, trying to remove them again, etc.)
- the write speed is rather slow: write speed of max. 8 MB per -minute- (compared to 150 MB per minute with NDIS2) Is this expected? I have not performed any other speed test using the packet driver for comparison, yet

Reply 19 of 109, by mateusz.viste

User metadata
Rank Member
Rank
Member
mOBSCENE wrote:

- I can actually read existing and newly created files, but removing newly created files does not work (even though they are created on the server with all upper-case) - error "File not found"
- during testing the connection to EtherSRV got dropped (drive listing empty) but I can not recall what action caused it (just copying files over, trying to remove them again, etc.)

Any chance you could confirm whether or not the above symptoms go away when running over FAT?

mOBSCENE wrote:

- the write speed is rather slow: write speed of max. 8 MB per -minute- (compared to 150 MB per minute with NDIS2) Is this expected?

EtherDFS is by nature slower than a TCP-based transfer, because it's highly dependent on the latency between both hosts. Although 8M/minute (ie 130 KiB/s) does sound a little slow-ish. I will see if there is any room for 'easy win' improvements there (performance wasn't really a priority until now).