I've tested every combination in my Amstrad XT and 386SX. I built 3 images for the Amstrad:

• xt_12.img using the command: netdrive create hd 10 fat12 xt_12.img
• xt_16.img using the command: netdrive create hd 10 fat16 xt_16.img
• xt_16b.img using the command: netdrive create hd 10 fat16b xt_16b.img

The first image, xt_12.img, works perfectly both in Amstrad and 386.
The other two, xt_16.img and xt_16b.img, are garbled in the Amstrad, but work in the 386.

So maybe the Amstrad doesn't accept fat16. But I'm pretty sure that mkfs.msdos uses fat16, and it was accepted by the Amstrad.

So I generated again xt_16.img and xt_16b.img with the commands given above, and computed their md5 sums, and they were identical. Could it be that the server is using fat16b in both cases?

Gentle peeps,

Couple of weeks ago I stumbled upon mTCP NetDrive and I really liked it as it ticked a lot of boxes. As I want to have this running in a more permanent manner I created a Docker image on https://hub.docker.com/repository/docker/smeed/netdrive so I can use it in my k8s homelab. Already shared this on the ITX Llama discord but I think this needs to be here as well.

cheers,
Martijn

Mannie wrote on 2024-11-02, 23:40:

I've tested every combination in my Amstrad XT and 386SX. I built 3 images for the Amstrad: […]
Show full quote

I've tested every combination in my Amstrad XT and 386SX. I built 3 images for the Amstrad:

• xt_12.img using the command: netdrive create hd 10 fat12 xt_12.img
• xt_16.img using the command: netdrive create hd 10 fat16 xt_16.img
• xt_16b.img using the command: netdrive create hd 10 fat16b xt_16b.img

The first image, xt_12.img, works perfectly both in Amstrad and 386.
The other two, xt_16.img and xt_16b.img, are garbled in the Amstrad, but work in the 386.

So maybe the Amstrad doesn't accept fat16. But I'm pretty sure that mkfs.msdos uses fat16, and it was accepted by the Amstrad.

So I generated again xt_16.img and xt_16b.img with the commands given above, and computed their md5 sums, and they were identical. Could it be that the server is using fat16b in both cases?

Hmm, not sure how I missed this reply. I really prefer (potential) bug reports through email so they don't get lost.

FAT16 and FAT16B are effectively the same format except for one difference - FAT16B allows for partitions larger than 65535 sectors and does so by using an extended field in the BIOS Parameter Block of the partition. You created 10MB partitions which are well under 32MB (65535 sectors), which is the reason why you can't see the difference in the image files.

Try creating a larger FAT16B disk to see what the Amstrad thinks of it. It has to be larger than 32 MB for it to be FAT16B.

mbbrutman wrote on 2023-12-10, 22:06:

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 […]
Show full quote

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.

@mbbrutman thanks for this wonderful tool. Just a couple of issues / feedback.

1. I’m trying to get it to run on 8x DOS machines with no DHCP server. I have IPX setup on each machine (they can all play Doom together) so I figured mTCP would be simple to get going 😉 The comments in the CFG file mention that to use a static IP, just enter the settings in the CFG file and don’t run DHCP.EXE. The problem is I can’t run PING.EXE or NETDRIVE.EXE without them complaining about the DHCP lease being expired. I’m not running DHCP 🙁

2. It would be good if you could make it clear that users need to source their own packet driver for their network card. It’s not included in the zip file you provide. Not so obvious if you’re doing this for the first time.

3. The example CFG file sets the packet driver interrupt at 0x60 but everywhere else it’s 0x63?

4. Is there a way to see your current TCP details? It would good if there was a tool (like ipconfig) you could use to see what is assigned to the NIC. Yes, you could edit the CFG file and have a look but how do you know if that IP has actually been assigned and is active (and that the user hasn’t made an error in the CFG file).

Hi,

1. The instructions for creating the static network configuration are pretty clear about deleting the DHCPVER and TIMESTAMP lines in the mTCP config file. If you don't delete those, it looks just like a DHCP configuration with an expired lease time.
2. The instructions have a sub-section called "Finding packet drivers" that lists 3 to 5 different web pages with packet driver collections. I have a separate page with my own drivers. I don't want to start bundling drivers with mTCP; there are better ways to distribute packet drivers.
3. These are samples and screen shots. I don't want people thinking that 0x60 is the only valid choice to use for the software interrupt so I mix it up.
4. There is no way to know "what is assigned to the NIC" on any system because that's not the way IP addresses work. The operating system either records the assignment from a DHCP server, or it is told what the address is. To know what is assigned you'd have to look at the DHCP serer, assuming it handed out the address. If you are using a static configuration it is whatever you told it to be, which is in the configuration file. This is the case no matter what your operating system. Ifconfig or ipconfig just present the assigned DHCP or static address to you from wherever the OS recorded it. With DOS and mTCP, that's in the mTCP configuration file.

mbbrutman wrote on 2025-01-26, 17:46:

Hi, […]
Show full quote

Hi,

1. The instructions for creating the static network configuration are pretty clear about deleting the DHCPVER and TIMESTAMP lines in the mTCP config file. If you don't delete those, it looks just like a DHCP configuration with an expired lease time.
2. The instructions have a sub-section called "Finding packet drivers" that lists 3 to 5 different web pages with packet driver collections. I have a separate page with my own drivers. I don't want to start bundling drivers with mTCP; there are better ways to distribute packet drivers.
3. These are samples and screen shots. I don't want people thinking that 0x60 is the only valid choice to use for the software interrupt so I mix it up.
4. There is no way to know "what is assigned to the NIC" on any system because that's not the way IP addresses work. The operating system either records the assignment from a DHCP server, or it is told what the address is. To know what is assigned you'd have to look at the DHCP serer, assuming it handed out the address. If you are using a static configuration it is whatever you told it to be, which is in the configuration file. This is the case no matter what your operating system. Ifconfig or ipconfig just present the assigned DHCP or static address to you from wherever the OS recorded it. With DOS and mTCP, that's in the mTCP configuration file.

1. My apologies, I should have read the PDF document from the website. I was just going by the YouTube video you made and the comments in the example CFG file.

2. I should have read the “Requirements” section on the main website. It clearly states an external packet driver is required.

3. Understood

4. Understood. A quick dirty way I found is just to ping yourself and if it complains you can’t ping yourself then it’s working.

I managed to get everything running perfectly across the 8x DOS machines (all different network cards). I just have one last question. If a session isn’t properly disconnected from the client side, the server no longer provides access to the .DSK file for future sessions. For example, if a game freezes and you have to reboot. The client can no longer connect to that .DSK file again until the server is restarted (/quit and rerun the .exe). Is there something I could be doing wrong?

After going through the PDF document and source code, it’s mind boggling how much effort you’ve put into this project. Really appreciate everything you’ve done.

The user interface on the server side lets you enter a "status" command to display which sessions are active, and a "kill" command to force disconnect a dead client. You don't need to restart the entire server if just one client has died; use the kill command to force that session closed.

Longer term I'll probably add an "auto reconnect" where a disk image is locked to a specific machine, removing the possibility of two machines writing to the same image at the same time. When I do that it will make NetDrive behave much more like a local hard drive; the server restarting won't hurt anything and the DOS machine won't have to do an explicit connect step.

It's been a fun project ... over 15 years now, with NetDrive being the newest part. I'm glad you are enjoying it. When you get a chance please send me a DM or post here with the list of network cards and machines you are using. I'm trying to fill out the packet driver section of my device driver page, so if you have something unusual I'd like to know about it to help others.

mbbrutman wrote on 2025-01-27, 17:40:

The user interface on the server side lets you enter a "status" command to display which sessions are active, and a "kill" command to force disconnect a dead client. You don't need to restart the entire server if just one client has died; use the kill command to force that session closed.

Longer term I'll probably add an "auto reconnect" where a disk image is locked to a specific machine, removing the possibility of two machines writing to the same image at the same time. When I do that it will make NetDrive behave much more like a local hard drive; the server restarting won't hurt anything and the DOS machine won't have to do an explicit connect step.

It's been a fun project ... over 15 years now, with NetDrive being the newest part. I'm glad you are enjoying it. When you get a chance please send me a DM or post here with the list of network cards and machines you are using. I'm trying to fill out the packet driver section of my device driver page, so if you have something unusual I'd like to know about it to help others.

Thanks for the status and kill commands. Really looking forward to the auto reconnect feature. I end up having to kill sessions multiple times a day 😉 I’ll put together a list of NICs for you. I’ve managed to use the same packet driver for the ISA cards and the same packet driver for the PCI cards.

I’ve come across a catch 22 problem. I haven’t seen anyone else raise this problem but it occurs on all my machines. You cannot use NETDRIVE and play a DOS IPX multiplayer game at the same time.

Any multiplayer game will freeze if the packet driver is running. It doesn’t matter what version of packet driver (including a PCI packet drivers) I use, the game will always freeze when I enter the multiplayer menu (C&C, Doom, Warcraft etc).

The problem is I’ve made an ISO of each game (which I own) as my CDROM drives, being so old, work 50% of the time with CD’s. I use NETDRIVE to connect to an image which contain the ISO images. I then mount the ISO using other software. So you can see the catch 22, I need to packet driver to run to be able to get to those ISO’s. I can’t run the packet driver and play multiplayer games.

I’ve tried multiple packet drivers. Multiple NICs. Multiple machines. I’ve also changed the order in which programs load in autoexec.bat. The only way to get multiplayer games to not freeze is to not load the packet driver. Have you got any ideas on how I could diagnose why packet drivers would be freezing IPX multiplayer games?

My autoexec.bat

LH C:\DRIVERS\NE2000\LSL.COM
LH C:\DRIVERS\NE2000\NE2000.COM
LH C:\DRIVERS\NE2000\IPXODI.COM
LH C:\DRIVERS\NE2000\E2000.COM 0x63 0xA 0x280

zuldan wrote on 2025-02-10, 09:43:

why packet drivers would be freezing IPX multiplayer games?

Because you're loading two drivers for one card - ODI and PD.

It is possible to use both IPX and PD-based TCP/IP applications at the same time, as they use different frame types:
- TCP/IP: Ethernet_II
- IPX: Ethernet_802.3 or Ethernet_802.2

If you need further assistance, show your NET.CFG file.

Grzyb wrote on 2025-02-10, 11:11:

Because you're loading two drivers for one card - ODI and PD. […]
Show full quote

zuldan wrote on 2025-02-10, 09:43:

why packet drivers would be freezing IPX multiplayer games?

Because you're loading two drivers for one card - ODI and PD.

It is possible to use both IPX and PD-based TCP/IP applications at the same time, as they use different frame types:
- TCP/IP: Ethernet_II
- IPX: Ethernet_802.3 or Ethernet_802.2

If you need further assistance, show your NET.CFG file.

Ok what do you mean I’m loading. 2 drivers? IPXODI.COM won’t load without NE2000.COM and NE2000.COM won’t load without LSL.COM. I’m a DOS networking noob so please tell me what I’m doing wrong 😜

1Protocol IpxOdi
2		Ipx Sockets = 32
3
4Link Driver NE2000
5		Int 10
6		Port 280
7		Frame ETHERNET_802.3
8		Protocol IPX 0 ETHERNET_802.3

"LH C:\DRIVERS\NE2000\NE2000.COM" is the ODI driver
"LH C:\DRIVERS\NE2000\E2000.COM 0x63 0xA 0x280" is the PD driver for the same card

THERE CAN BE ONLY ONE!

Wait, I'm about to try making IPX and TCP/IP work together on my machine...

Grzyb wrote on 2025-02-10, 11:32:

"LH C:\DRIVERS\NE2000\NE2000.COM" is the ODI driver "LH C:\DRIVERS\NE2000\E2000.COM 0x63 0xA 0x280" is the PD driver for the sam […]
Show full quote

"LH C:\DRIVERS\NE2000\NE2000.COM" is the ODI driver
"LH C:\DRIVERS\NE2000\E2000.COM 0x63 0xA 0x280" is the PD driver for the same card

THERE CAN BE ONLY ONE!

Wait, I'm about to try making IPX and TCP/IP work together on my machine...

If you get TCP and IPX working on a machine without crashing a multiplayer game, I’ll be super impressed. May the force be with you…

Try the following:

1LH C:\DRIVERS\NE2000\LSL.COM
2LH C:\DRIVERS\NE2000\NE2000.COM
3odipkt 1 0x63
4LH C:\DRIVERS\NE2000\IPXODI.COM

You need the attached ODIPKT.COM

1Link Support
2		Buffers 6 1600
3
4Protocol IpxOdi
5		Ipx Sockets = 32
6
7Link Driver NE2000
8		Int 10
9		Port 280
10		Frame ETHERNET_802.3
11		Frame ETHERNET_II
12		Protocol IPX 0 ETHERNET_802.3

Grzyb wrote on 2025-02-10, 12:22:

Try the following: […]
Show full quote

Try the following:

Copy code to clipboard

1LH C:\DRIVERS\NE2000\LSL.COM
2LH C:\DRIVERS\NE2000\NE2000.COM
3odipkt 1 0x63
4LH C:\DRIVERS\NE2000\IPXODI.COM

You need the attached ODIPKT.COM

Copy code to clipboard

1Link Support
2		Buffers 6 1600
3
4Protocol IpxOdi
5		Ipx Sockets = 32
6
7Link Driver NE2000
8		Int 10
9		Port 280
10		Frame ETHERNET_802.3
11		Frame ETHERNET_II
12		Protocol IPX 0 ETHERNET_802.3

I think Doom is working now and not freezing. Only managed to do a quick test.

However….

Command & Conquer (and other games I mount the ISO for over the network via NETDRIVE) complains about the CD not being present if odipkt is used. SHSUCDX loads the ISO and mounts the drive with the C&C files, everything appears to be working. There must be some weird conflict between SHSUCDX and odipkt.

Would you be able to explain the changes you made to net.cfg and how odipkt is different to the packet driver I was using. I would like to understand what’s changing.

Ok found the reason why C&C complains there is no CD. Any files in the image NETDRIVE mounts cannot be access. You can type dir and it lists the files in the image, but none of them can be accessed "Read fault error reading drive". So it appears ODIPKT.COM is not compatible with NETDRIVE 🙁

Edit:

It appears some people are using mTCP and ODIPKT.COM (no mention of NETDRIVE though) https://www.zx.net.nz/netware/client/dos-pack … t-drivers.shtml

I saw something interesting at the end of the page…

Ethernet_II frame type (the only frame type supported by packet drivers)

That means Frame Ethernet_802.3 is not compatible with packet drivers, and that’s the frame type I’m using. I’ll change to Ethernet_II and see what happens. Other than that I’m not sure what to try.

zuldan wrote on 2025-02-11, 07:27:

Command & Conquer (and other games I mount the ISO for over the network via NETDRIVE) complains about the CD not being present if odipkt is used. SHSUCDX loads the ISO and mounts the drive with the C&C files, everything appears to be working. There must be some weird conflict between SHSUCDX and odipkt.

Ah, that's a completely different problem - and I'm afraid it may be impossible to solve without total rewrite of all the involved tools.

It's all described there - DOS/SMB/Mounting images

In short: don't expect SHSUCDHD+SHSUCDX to work correctly with an ISO image located on a remote drive.
It didn't work for me with Microsoft Network Client 3.0, and it probably can't work for you with NetDrive.

If using NetDrive, the workaround may be:
- don't use SHSUCDHD+SHSUCDX
- don't use ISO images
- use FAT disk images instead: copy all the files from an ISO image into a FAT image, and mount the FAT image on the DOS machine using NetDrive
- you may need some CD-ROM emulation utility to prevent games complaining that the NetDrive disk is not a CD

Would you be able to explain the changes you made to net.cfg

1.
Added support for ETHERNET_II frame type.
Now it supports two frame types, and two "logical boards":
1. (ODIPKT numbers it 0) ETHERNET_802.3 - like before, used by IPX, ODIPKT doesn't touch these frames
2. (ODIPKT numbers it 1) ETHERNET_II - this logical board is handled by ODIPKT, which provides it via INT 0x63 to Packet Driver applications, and they use it for TCP/IP

2.
Added the "Link Support" section, as recommended by the ODIPKT documentation.

WARNING!
For some hardware configurations, "Buffers 6 1600" may be not enough - try changing it to "Buffers 16 1600".
Sometimes it may improve performance, but I don't think it can solve the problem with SHSUCDHD+SHSUCDX.

how odipkt is different to the packet driver I was using.

Packet Driver directly handles the physical NIC.
And so does the ODI driver - therefore they conflict with each other.

ODIPKT doesn't touch the physical NIC.
It only handles one of the "logical boards", ie. frame types - passed to it by the LSL + ODI driver.

That means Frame Ethernet_802.3 is not compatible with packet drivers, and that’s the frame type I’m using. I’ll change to Ethernet_II and see what happens.

Again: you need both.
Ethernet_802.3 for IPX multiplayer games.
Ethernet_II for PD-based TCP/IP software.

zuldan wrote on 2025-02-11, 08:27:

Ok found the reason why C&C complains there is no CD. Any files in the image NETDRIVE mounts cannot be access. You can type dir and it lists the files in the image, but none of them can be accessed "Read fault error reading drive". So it appears ODIPKT.COM is not compatible with NETDRIVE 🙁

OK, I can recreate your problem...

My setup is:
- 486DX2-66
- 3C509B-Combo, using the TP transceiver
- MS-DOS 6.20
- mTCP 2025-01-10

With the Packet Driver, everything is fine:
- FTP download to NUL speed is 784 KB/s
- no problem with NetDrive

After replacing the PD with ODI+ODIPKT (attached):
- FTP download to NUL speed is 912 KB/s - yes, works fine, and even faster than with the PD
- NetDrive mounts the remote image, allows to list the files, but any attempts to read a file quickly end up with:

The attached stuff is the simplest usage of ODIPKT - Packet Driver substitute, and nothing more.
But I also tried the setup with IPX support - same problem.

Hi ...

Can you try pinging the DOS machine from a few different machines? And then run "netdrive status d:" and post the results?

It won't respond to ping, but it should respond to ARP. So if you try from a few different machines and the received ARP counter does not move, that means NetDrive is not seeing the packets.

The last time something like this happened it was a bug in the packet driver. EtherSlip was telling NetDrive one MAC address at setup time, and another MAC address on the received packets. I'm wondering if something similar is happening here.

mbbrutman wrote on 2025-02-11, 18:24:

Can you try pinging the DOS machine from a few different machines? And then run "netdrive status d:" and post the results?

I did the following:
1. loaded ODI+ODIPKT
2. connected the remote image
3.

4. pinged the DOS machine from the server, where it was already in the ARP table - no response
5. pinged the DOS machine from yet another box - no response, but it got added to the ARP table
6.

Ok, I didn't expect to see the ARP counter going up so maybe there is something else going on.

However, inside of ODIPKT.ASM receive routine I found this:

1	cmp	al, 212
2	jnz	rcvna6
3	mov	ax, 0800h
4	jmp	short rcvna7
5rcvna6:	cmp	al, 213
6	jnz	rcvna7
7	mov	ax, 0806h
8rcvna7:	xchg	ah, al
9	mov	es:12[di], ax
10	push	di
11	mov	cx, 6
12	xor	ax, ax
13	rep	stosw

So that's moving the EtherType (0800) into the packet and then moving six words of 0's into the beginning of the packet, which is suspicious. (Those six words should be the source and target MAC address.)

I might craft up some debug code later ...