zuldan wrote on 2025-02-14, 22:46:

Maybe a workaround is to extract the ISO on the Netdrive disk image then use 0CD.COM to mount the files as a CDROM?

Sure, there's plenty of workarounds, but that's not my goal.

The goal is: check if SHSUCDHD+SHSUCDX can reliably work with an ISO image located on a remote drive.

I was told not - due to the network and/or protocol latency.
And indeed it did cause random hangs for me before.

But with my current setup, it works reliably.
It's slow, but reliable.

(Starting a new thread for the SHSUCDX performance discussion.)

Is there a particular reason I cannot get netdrive to run on my windows 11 pc? It tells me, it is incompatible with the version of windows I'm running, and to contact the software publisher. It says it cannot run under 64-bit windows. I plan to run it on my Debian 12 headless NAS but I wanted to test it out on my main before I committed to it.

Demo wrote on 2025-03-07, 16:40:

Is there a particular reason I cannot get netdrive to run on my windows 11 pc? It tells me, it is incompatible with the version of windows I'm running, and to contact the software publisher. It says it cannot run under 64-bit windows. I plan to run it on my Debian 12 headless NAS but I wanted to test it out on my main before I committed to it.

The server works fine for me.

Perhaps you're trying to run the client, a DOS EXE ?

Yeah I'm an idiot... 🤣 I see them now I just assumed it was the netdrive.exe in the mtcp zip thank you!

smeedy wrote on 2024-12-27, 12:23:

Gentle peeps, […]
Show full quote

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

Hey Martijn

Thanks for creating the docker image, really appreciated and something I've setup on my Synology NAS. I'm just wondering how to set timeout and other server settings? Atm it's really annoying if my DOS computer crashes (or I forget to disconnect on shutdown/restart) as the image files (I'm using them in RW mode) then become locked and requires restart of docker image.

@mbrutman: Wish feature is a switch to override control of the image in the netdrive connect command (force disconnect other sessions). Am understanding it correctly that wait for timeout or use kill command on server/restart is the other options atm?

Hi,

I originally designed it with a text UI, and there is a kill command you can run in that UI. If you are in "headless" mode then that option isn't available.

Sometime soon I'll add a "force reconnect" if an abandoned session to the same image and machine is detected. That's a reasonable work around. Stay tuned.

mbbrutman wrote on 2025-03-25, 20:20:

Hi,

I originally designed it with a text UI, and there is a kill command you can run in that UI. If you are in "headless" mode then that option isn't available.

Sometime soon I'll add a "force reconnect" if an abandoned session to the same image and machine is detected. That's a reasonable work around. Stay tuned.

It runs in "headless" mode inside the Docker image. Thank you for confirming there is no options I've somehow missed.

"force reconnect" feature sounds perfect for this usecase. Looking forward to it!

Trying to get the NetDrive packetdriver shim to work, but whatever I do I get the following error message when running DHCP:

"Init: Could not setup packet driver, are the configured interrupts correct? Configured packet driver interrupt: 0x%X"

What am I doing wrong?

System: Olivetti M28 286 /w 1mb of RAM
DOS version 3.10 (but I've also tested with PC-DOS 6.1)

Packetdriver: 3C503.COM 0x60 3 0x280

MTCP.CFG:
PACKETINT 0x60, 0x65
MTU 1500

Packetdriver loads as normal
Then I start DHCP and get the message above. It does read "NetDrive packet driver shim installed at 0x65" (message might be slightly different as I'm doing from memory).

Everything works fine when I only have PACKETINT 0x60 in MTCP.CFG (except that other mTCP programs do not run with Netdrive)

Are all of the mTCP programs (including the NETDRIVE.SYS pointed at by the CONFIG.SYS) file updated? I think they have to be at least as new as last October, when I added the "shim" trick. Sometimes people forget to update the SYS file from wherever it is being loaded.

Was the mTCP configuration file updated with PACKETINT listing two software interrupts *before* you ran NETDRIVE.EXE the first time? The second software interrupt has to be present when NETDRIVE.EXE runs so that it knows to setup the secondary shim packet driver. If you forgot to do that, then edited it and tried to run something else, it won't work.

Yes, using the latest 10th of January release files, including netdrive.sys and yes, both interrupts are there. I've cleared out the cfg file for old DHCP data to just have the two lines shown above. I dont even run NetDrive.exe, as the issue above happens when I try to run DHCP.exe after the ethernet packet driver (3c503.com).

I will test with a 3c509 network adapter in my 386, just to rule both system and network card/driver out.

Hi,

Don't change cards are anything ...

On the same machine (Olivetti M28 286) reboot and before you do anything, run debug.com so I can see the contents of the memory:

1debug
2-d 0:180
30000:0180  00 00 00 00 ...
40000:0190  00 00 00 00 ...

If you can get a picture of the contents that will confirm a theory I have. Assuming you are using PACKETINT 0X60, 0x65 then just the first two lines are all I need.

Thanks,
Mike

Here is the command after startup. Netdrive.sys have loaded, but not the ethernet packet driver, nor DHCP.

Ok, that's the problem. Unused software interrupts are normally set to 0, while on your machine they are set to F000:1805. The NetDrive code is very careful to check the secondary software interrupt to ensure that it's not stepping on anything, and that it's also not in use.

You can get around this by zero'ing out the specific bytes for software interrupt 0x65. To do that use debug again:

1debug
2e 0000:0194
300
400
500
600
7<press enter to stop>

That sequence is from memory so it might not be exact, but the goal is to get the four bytes at 0000:0194 to zero before you start anything else.

Your packet driver must be installing itself at 0x60 (memory 0000:0180) without checking to see if something is there first, which is why it doesn't complain. I'm not that bold yet.

Is it really necessary to use two software interrupts?

Can't NETDRIVE.SYS provide its PD emulation at the same interrupt number as the real PD?

When the PD is in use by NETDRIVE.SYS, other programs shouldn't use it - so it would be nice to "hide" the real PD interface.

It's just code. Anything is possible.

I chose to do it this way because the secondary "shim" packet driver that NetDrive creates looks and feels exactly like any other packet driver client to the packet driver - it accesses it via a software interrupt.

If I tried to take over the packet driver interrupt and hide it, then I'd have to do far calls to the packet driver instead. Which are not quite the same as doing software interrupts, and potentially exposes other problems because that is not how packet drivers are usually invoked or tested. I also don't want the shim packet driver to be installed and in use unless it absolutely needs to be. That protects the system from bugs in it ... even if the shim fails for some reason, the original packet driver is still available and accessible.

There are at least 16 software interrupts available, even on a well configured system with lots of TSRs and utilities. Using a second software interrupt should not be an issue.

mbbrutman wrote on 2025-03-31, 17:39:

Ok, that's the problem. Unused software interrupts are normally set to 0, while on your machine they are set to F000:1805. The […]
Show full quote

Ok, that's the problem. Unused software interrupts are normally set to 0, while on your machine they are set to F000:1805. The NetDrive code is very careful to check the secondary software interrupt to ensure that it's not stepping on anything, and that it's also not in use.

You can get around this by zero'ing out the specific bytes for software interrupt 0x65. To do that use debug again:

Copy code to clipboard

1debug
2e 0000:0194
300
400
500
600
7<press enter to stop>

That sequence is from memory so it might not be exact, but the goal is to get the four bytes at 0000:0194 to zero before you start anything else.

Your packet driver must be installing itself at 0x60 (memory 0000:0180) without checking to see if something is there first, which is why it doesn't complain. I'm not that bold yet.

That actually worked. I cleared out 0194, 0195, 0196, 0197 and 0198 and then ran DHCP.

I also checked this on my 386 where it worked out of the box. Debug there showed all 00 for 0180 to 019f range.

So is this something you can fix in a future version, or should I look around to either figure out what is filling this memory section or include in autoexec.bat some way to clear these bytes?

Usually the BIOS of the machine sets those values. Zeros are the normal "this is not in use" value. Sometimes a BIOS will get clever and put a pointer to an "IRET" instruction there instead, so if somebody tries to make a call to an uninitialized software interrupt the call will not crash the machine. Except there is no standard value for where that IRET instruction should be ...

I'm not going to fix this in mTCP because I'd have to keep adding special cases for all of the different BIOSes that do this. I added code for the PCjr, as there are a lot of them and it's my favorite machine.

Before somebody says "You could look at the address and see what is there before deciding whether it is used or not" it's not always a single IRET instruction. It just gets too complicated.

My suggested solution: Create a small text file with what you typed into DEBUG to clear those bytes out, then run DEBUG.COM with input from that script file after you run your packet driver.

mbbrutman wrote on 2025-04-01, 21:49:

...
I'm not going to fix this in mTCP because I'd have to keep adding special cases for all of the different BIOSes that do this. I added code for the PCjr, as there are a lot of them and it's my favorite machine.
...

An IRET (or any more complicated "do nothing" function) doesn't really help,
as that just masks the fact that something called an uninitialized int.

What would be ideal would be if BIOS could report it!
But.. there's no standard method of BIOS reporting an error other than "blue screen"
and restart. (it would be more a lot work as you would have to save/restore any video
state, but "blue screen" long enough delay to read why and then resume would probably
be best!

I suppose there's some rational for ignoring the int ... vectoring to zero
would crash with no indication why (in that case I'd prefer a fatal blue screen)

Does BIOS ever actually use these ints for any functional purpose? (A BIOS might netboot,
but that wouldn't need a general vector)

Might it be work just checking to see if the vector is zero -or- points
into the BIOS code area.

BTW: I've not looked at mTCP in quite a while and wanted to play with it a bit - where's the
best place to get the latest stable release? (the link you posted early in this thread?)

mbbrutman wrote on 2025-04-01, 21:49:

My suggested solution: Create a small text file with what you typed into DEBUG to clear those bytes out, then run DEBUG.COM with input from that script file after you run your packet driver.

Will do 😀

Could it be an idea to have a switch to force overwrite the interrupt location like the 3c503 packet driver does? The same bytes exist at 180-184 and they are overwritten once the packetdriver is run. It doesnt care what exist there before.