mTCP NetDrive is available!

[Michael Brutman]

mTCP NetDrive is a DOS device driver that allows you to access a remote disk image hosted by another machine as though it was a local device with an assigned drive letter. The remote disk image can be a floppy disk image or a hard drive image.

Use it to:

• Add temporary extra space to a DOS machine.
• Mount your library of floppy images directly on your DOS machine.
• Create a repository of utilities or files that all of your DOS machines can share.
• Provide a quick and easy backup target for Xcopy or Zip.
• Add hard drive-like storage to machines that don’t have a hard drive.

Features:

• A single device driver works with all versions of DOS starting with DOS 2.0.
• It uses less than 6KB of RAM. (Add another 5 to 10kB depending on your Ethernet card.)
• DOS 3.31 and up can use remote images up to 2GB in size. (Earlier versions of DOS are limited to 32 MB because they use FAT12 or original FAT16.)
• The server runs on Windows (10 or 11) or Linux. No special permissions are needed.
• The protocol uses UDP so you can use it on your private network or across the Internet. (Yep - start your own cloud storage business for DOS PCs!)
• Network drives are standard raw disk images that can be manipulated using Linux tools.

If you use mTCP today it is as simple as installing the device driver and then running a command line program to attach or detach the remote storage.

Details and downloads can be found at http://www.brutman.com/mTCP/mTCP_NetDrive.html.

-Mike

[Dominic Raferd]

I have this working (Versions: Dec 10 2023 for server, Dec 30 2023 for
client), so far only on a test basis. Seems really great, and should
allow us finally to stop using Microsoft DOS Networking and so remove
the SMBv1 dependency. Server is Linux (Ubuntu 22.04), and client (MS-DOS
6.22) access is via local LAN.

I already had mTCP and a packet driver set up on the client, so that
side was very easy (add one line to CONFIG.SYS, then one 'netdrive
connect' command to 'map' the drive). The server side was also pretty
straightforward (in my case: create loop file device [using 'netdrive
create hd'], mount it, populate it with data [using rsync, ignoring
permission errors], umount it, make a port available through the
firewall, start the server [using 'netdrive serve']. It's nice that the
user running 'netdrive serve' can have limited permissions.

Small points/requests, mostly re the documentation:
- Server documentation says there is a 60 minute default timeout but in
fact the default (at least for Linux server) appears to be 0, which is
presumably an (undocumented) setting for no timeout (which is required
for my use case)
- The serving mode -log_file flag is shown in an example but not
mentioned in the list of available flags
- I find the documentation order strange, I used it almost in reverse:
first create an image file on the server, then set up serving mode, then
move back to the beginning to set up the DOS client and then connect it
to the server
- Presumably the netdrive-serve process can be run in the background? Is
there a recommended way to do this, and if so, then when there is no
front-end, can the server communicate with this process (including
instructing it to shut down, apart from just killing it)? I am thinking
of automated communication (for instance: check that no client is
connected, then shut down netdrive-serve, so that we can mount the drive
locally and access the [modified] data)

Great work Mike, many thanks.

Dominic

On 10/12/2023 20:47, Michael Brutman wrote:
> mTCP NetDrive is a DOS device driver that allows you to access a
> remote disk image hosted by another machine as though it was a local
> device with an assigned drive letter. The remote disk image can be a

> floppy disk image or a hard drive image...

[Michael Brutman]

Remember, this is not a direct replacement for SMB.  But it is handy for providing extra storage on demand.

• The 60 minute session timeout doesn't match; it was a late change.  I'll fix that.
• -log_file flag is a global flag not specific to serving, and it's covered.
• I'll be adding a "daemon" mode for background operation, and it will follow the normal convention of honoring SIGTERM to end the process.  I can also add support for another signal (SIGHUP maybe?) to just flush clients without shutting the server down.

-Mike

[Dominic Raferd]

Thanks Mike. For the daemon mode, another useful function would be to tell what clients, if any, are currently connected (or, if that is too difficult, just how many clients are currently connected). So we know if it is 'safe' to end the process.

--
You received this message because you are subscribed to the Google Groups "mTCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mtcp/8b9dd91c-6d46-4f63-935d-eff9a2c6fdf3n%40googlegroups.com.

[Michael Brutman]

Dominic,

It wouldn't be difficult to add a TCP/IP port for getting status from the server, but the bigger question is why?

A normal Unix daemon starts when the system starts and ends when the system ends, or when the subsystem is shut-down.  There really isn't any concern about connected clients, whether it's the FTP server, SMB server, or Telnet server - if the daemon is told to shut down, it does what it can gracefully, but it will shut down.  Adding a status mechanism never really solves the problem of how to handle connected clients because you always have a race condition; clients can be coming or going at the same time the status is being transmitted.

So for a classic Unix-style daemon responding to signals should be enough.  Are you trying to integrate this into something else where the requirements are more stringent?

-Mike

[Dominic Raferd]

Now testing the actual (and physical) client machine, which (weirdly I
know) runs Win98 DOS. Have the packet driver (NE2000.COM) set up and
working, also PING and HTGET working to the server fine, but trying
NETDRIVE I see:

> C:\NET>netdrive connect 192.168.0.3:2002 my.dsk D:
> mTCP NetDrive by M Brutman (mbbr...@gmail.com) (C)opyright 2008-2023
> Version: Dec 30 2023
>
> Error: IOCTL read failed. Did you specify the right drive letter?
>
I have tried with different drive letters and different LASTDRIVE
settings, but nothing works. The server shows no sign of any contact
from the client. UDP port 2002 is definitely open to the client on the
server.

At the same time the setup on my test machine (a VM running DOS 6.22)
works fine and can connect to the server with NETDRIVE and access the
files there (this uses a different packet driver).

Suggestions gratefully received...

[Michael Brutman]

That's a pretty fundamental error - you've specified a drive letter that is not controlled by the device driver.  When the device driver loaded from CONFIG.SYS what drive letter did it report that it was assigned?  DOS 3.x and up will tell you the letter directly when the device driver loads.

[Dominic Raferd]

Doh. I forgot to add the line 'DEVICE=NETDRIVE.SYS' to CONFIG.SYS. Will try again. Sorry for the noise...

[Dominic Raferd]

Mike

I now have NETDRIVE working on the 'real physical client', sorry for my earlier confusion. Back to the original question...

It is because of the risk of a client coming and going when the server has to access files on the DOS drive that it would (I think) be best to close down (or, see below, pause) the server at these (rare) moments. 

Stop/start solution:

• If the netdrive daemon can confirm that no one is connected, then it is pretty safe to shut it down so that the files can be accessed by the server (it is not absolutely safe I accept, because a client might be just about to connect).
• In my use case the risk of simultaneous changes to the file structure, corrupting the drive, is in any case small but this would make it infinitesimally so.
• An alternative (to a response to the question 'is there a client connection?') that might be easier to implement would be a 'quit-if-no-client-connection' command (as well as the no-holds-barred 'kill' and 'quit' commands). If the first fails (giving an indicative response) then the server could wait to try again later.

Paused client access:

• The access required by the server to the DOS drive might well be read-only and very brief (basically just to check for new files and then read them), so in this case an ideal solution would be for the netdrive daemon to keep any connected client waiting (say only the fraction of a second required to take an LVM snapshot) and then continue responding to the client once the snapshot is prepared; this way the client retains its existing connection. This would require 'pause' and 'unpause' commands. If the time lapse was too great I imagine the DOS client would throw an error, perhaps the client-side timeout might need tweaking to avoid this scenario.
  

Dual access:

• Alternatively maybe I can just do dual access (i.e. mount the drive system on the server while it could still be serving a client), ignoring all your warnings? I would rather not do this but if it works then (in my case) the downside risk is small. The server would (almost always) be reading files, not writing.

I hope my thought process is helpful...

Dominic

--
You received this message because you are subscribed to the Google Groups "mTCP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mtcp+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mtcp/f33c2a7d-31ec-4f79-90b9-56ac745e2176n%40googlegroups.com.