6 buffers is not enough.
See my configuration for using mTCP with ODI...

net.cfg

1Link Support
2  buffers 16 1600
3Link Driver 3c515
4  Frame Ethernet_II

.bat

1lsl
23c515
3odipkt 0 0x60

Just replace "3c515" with the ODI driver for your NIC.

Edit: actually, the necessary number of buffers may vary...
On a 386DX-40 with 3C515, 16 buffers was necessary for good performance.
Now I did several test on a Celeron-266 with C-Net CN200 Pro, and it doesn't seem to care about the number of buffers - I tried 16, 8, 6, 4, 2, 1, and the FTP download speed was always about the same!

Thanks for your advice!
I changed the buffers to 16; but the result stays the same.

Thus chkdsk fails; with same error message.
netdrive status before: 0 retries
netdrive status after: 8 retries

To ensure packet driver is working correctly I tested htget as well with a 200Mb test file; that worked fine!

Did another test on the same machine; booted by PXE and used the UNDIPD (PXE Packetdriver).
- Netdrive.Sys loaded
- Ran UNDIPD 96
- Ran DHCP
- Ran netdrive connect w/o error (IOCTL_read return code: 4 029D:0020)
- Freeze after approx 3 seconds (Thus I am able to type on the command prompt for a couple of seconds)
- Replaced MSDOS 6.22 with Freedos 1.3 --> Same result

It seems something in netdrive is not playing nicely with this specific netbook 😉

Doesn't seem to be workign with an ESP8266-based SLIP network connection on my t1k, but using xircom parallel nic works fine.

netdrive looks basically identical on execution except that "Next hop address: FF:FF:FF:FF:FF:FF" for the SLIP connection vs. an actual mac address for xircom, followed by an IO error abort/retry/fail when it shoudl be dropping me back to the dos prompt.

What speed do you have the serial port running at?

mbbrutman wrote on 2024-02-13, 21:39:

What speed do you have the serial port running at?

115200. It works fine with other mtcp apps.

Ok, trying again because I'm tired of re-editing ...

Somebody with a 286 Toshiba laptop was able to make it work at 115,200, but they were probably using a local server.

The timeout is 1 second, and you get 2 retries before the device driver reports a timeout to DOS. Even on a slower 8088 at 115,200 you should be fine and avoiding the timeout. What region are you in? Can you tell me what your ping time is while using the ESP8266 device? (The ping should be to brutman.com.)

-Mike

mbbrutman wrote on 2024-02-13, 23:33:

Ok, trying again because I'm tired of re-editing ... […]
Show full quote

Ok, trying again because I'm tired of re-editing ...

Somebody with a 286 Toshiba laptop was able to make it work at 115,200, but they were probably using a local server.

The timeout is 1 second, and you get 2 retries before the device driver reports a timeout to DOS. Even on a slower 8088 at 115,200 you should be fine and avoiding the timeout. What region are you in? Can you tell me what your ping time is while using the ESP8266 device? (The ping should be to brutman.com.)

-Mike

I'll try locally. My ping to brutman.com is 48ms average.

Eh, no go locally either. Same behaviour. I shall tinker for a bit with some things, like MTU, and try from different machines.

48ms is not bad, but that's also a much smaller packet size than what you would see with a disk sector or two. Based on the timing information I don't think you are timing out because of the speed of the connection or the speed of the computer.

Other things to do:

• If you get the "Abort, Retry, Ignore" failure try Retry once or twice to see if that works.
• Run the netdrive status command to see how many retries it is reporting overall. I'm going to bet that is a non-zero number.
• Are you using the Dec 30th (latest) version of the device driver? I found a UDP checksum error in the very original version (Dec 10th) that can cause packet drops.
• The MTU is set correctly because the EXE program checks that. I think EtherSlip and the ESP8266 devices use an MTU of 1500 so they should be fine. What exact DOS SLIP driver are you using? Can you run FTP across it?

Forget all of that, I think I figured it out. Are you using ETHERSL.COM? If so, that's the problem.

I query the packet drive to get the MAC address, which in this case is simulated. But what it gives me when a packet arrives doesn't match what it told me so I never recognize it in the device driver. The other mTCP programs are not affected because they are not as strict about the incoming packet having the correct MAC address.

As a work around, try the older CSLIPPER driver. It doesn't have this problem and I tested it with an ESP8266 device against a local and my public server at 9600 bps. It was horrible to use, but it worked.

If you are not using ETHERSL.COM then can you email me the SLIP driver that you are using?

mbbrutman wrote on 2024-02-14, 04:46:

Forget all of that, I think I figured it out. Are you using ETHERSL.COM? If so, that's the problem. […]
Show full quote

Forget all of that, I think I figured it out. Are you using ETHERSL.COM? If so, that's the problem.

I query the packet drive to get the MAC address, which in this case is simulated. But what it gives me when a packet arrives doesn't match what it told me so I never recognize it in the device driver. The other mTCP programs are not affected because they are not as strict about the incoming packet having the correct MAC address.

As a work around, try the older CSLIPPER driver. It doesn't have this problem and I tested it with an ESP8266 device against a local and my public server at 9600 bps. It was horrible to use, but it worked.

If you are not using ETHERSL.COM then can you email me the SLIP driver that you are using?

Yep 100% using ethersl. I'll check out CSLIPPER. I don't expect it to be very usable but I'd just like to tinker with it anyway!

I have a better solution .. I've patched ETHERSL.COM and tested it and it's fine now. I'll post the patched version later today.

I did not expect to find a bug like that in 30+ year old code ...

Try this:

http://www.brutman.com/mTCP/download/EtherSlip_patched.zip or https://www.brutman.com/mTCP/download/EtherSlip_patched.zip

-Mike

I'll try your patched version but slipper driver did work, so far at least. It also seems a bit faster than my gotek floppy drive at 115200, it's honestly quite usable locally. It'll definitely fill in a few gaps in my setup, like when I want to PRINT and have network access at same time!

It's hard to beat the flexibility of shared read/write volumes that etherdfs gives, but etherdfs isn't routable so won't work outside local network. It's gonna be nice having a network drive on my book8088 and hp200lx The book8088 even has a built-in USB port to power the serial/wifi adapter...

A 360K floppy drive can do 10 or 11KB per second, assuming the head doesn't have to move. SLIP at 115,200 is good for at most 10KB/sec.

The next version of NetDrive will support multiple drive letters at the same time, even across different servers. At home I've created a shared "utilities" drive that all of my machines can mount. With the multiple drive support each machine can mount it's own private drive, or other shared drives. It was hilarious adding 8GB (4 drives at 2GB each) at a time with just four commands at the DOS prompt.

mbbrutman wrote on 2024-02-15, 19:07:

A 360K floppy drive can do 10 or 11KB per second, assuming the head doesn't have to move. SLIP at 115,200 is good for at most 10KB/sec, while compressed SLIP might do better depending on your CPU speed and the data being transferred. So yes, it might be faster than the floppy.

The next version of NetDrive will support multiple drive letters at the same time, even across different servers. At home I've created a shared "utilities" drive that all of my machines can mount. With the multiple drive support each machine can mount it's own private drive, or other shared drives. It was hilarious adding 8GB (4 drives at 2GB each) at a time with just four commands at the DOS prompt.

You're mounting that utilities folder as a read-only drive I assume? It doesn't support multiple r/w sessions to same images beyond the session scoped writes?

Yes, it has to be mounted read-only. But for a repository of utilities that's not a significant limitation; just set it in your path and run the programs from it, presumably acting against data on a RW drive. If you do have to update it then mount it RW. I generally don't have multiple vintage machines on at the same time so even RW usage has not been an issue. It is really handy to have a central repository of programs though.

The other big change in the works is read-aheads, which will help the speed on remotely connected drives. It's pretty easy to detect when more blocks are going to be read, so it's not a dumb read-ahead feature that just always grabs more blocks than it needs. On a single LAN it's not needed but across the Internet it will be a huge win.

keenerb wrote on 2024-02-15, 18:30:

I'll try your patched version but slipper driver did work, so far at least. It also seems a bit faster than my gotek floppy drive at 115200, it's honestly quite usable locally. It'll definitely fill in a few gaps in my setup, like when I want to PRINT and have network access at same time!

Did the patched EtherSL.COM work for you?

The next version of mTCP NetDrive is available. This version (2024-02-18) adds support for multiple drive letters so you can connect to several images from different servers at the same time.

• If you can use FAT16B you can add up to 48 GB of storage across 24 drive letters. (FAT12 users are limited to 768MB.)
• Each additional drive letter costs 96 bytes in the device driver and 48 bytes in DOS. Even fully maxed out it requires only 9KB of RAM + the space for the packet driver.
• No changes to the server side .. everything is compatible.

See http://www.brutman.com/mTCP/mTCP_NetDrive.html for details.

Yoghoo wrote on 2023-12-13, 18:52:

mbbrutman wrote on 2023-12-13, 15:44:

It's not enjoy, it just doesn't have boot code in the first sector. It will mount using DOS and Linux and there will be no files or volume label on it.

True, but if a more compatible boot code was used during the creation of the image file with NetDrive it would be more compatible with external (Windows) tools. You can't open an image file created by NetDrive with 7-zip or PowerISO for example. If you reformat that image file (after mounting it with OSFMount or so) you can use those tools to open and manipulate those images. It also still works with NetDrive. Not necessary of course as there is a workaround but would be a nice feature request.

Do you know of any other windows tools that can make/manage a raw disk image to use with netdrive, or convert it to something 7z can use? I was wanting to avoid linux with this but winimage is clunky to use plus i dont own it, and osfmount somehow nuked my windows efi boot partition, that was fun. Though if i have to i could use linux to create the disk files for netdrive to use and then use other windows tools to manage it

As for feedback: +1 on the ability to pick a drive letter for netdrive to use, and being able swap floppies server side would be handy too. Also it would be nice if you could list the disk images available in a server from the client, would help mistyped image names or managing servers with lots of disk images.