Personally, I would like to be able to connect old computers via a COM port to more modern ones for Internet distribution

I haven't recently checked - Does the telnet program support Z-modem? There are some telnet BBS'es that don't support X- nor Y-modem protocol, unfortunately...
Maybe the modem capability can be implemented as a proxy program for packet driver as i think NetDrive has (or will have) the capability? I remember that one reason for lack of z-modem protocol was that telnet binary was getting too big?
All in all, it would be a great addition. 😀

Oh, and another idea, but that might be too much work and not worth it. What about FTP client that mounts the server as a drive? Like NetDrive, but over FTP?
Theoretically, if i understand it correctly, you already have all the bits and pieces for it?

Turboblack wrote on 2024-09-28, 09:50:

Personally, I would like to be able to connect old computers via a COM port to more modern ones for Internet distribution

I think that problem is solved already.

mTCP supports SLIP and PPP connections over a serial port. You can use a null-modem cable to anything that runs Linux or you can use one a WiFi serial adapters with a SLIP firmware on it. If connected to a Linux machine the Linux machine will do the routing for you and make it look like your machine is directly on the network. When using a WiFi serial adapter with SLIP firmware you can connect directly to your WiFi access point, but the adapter makes it look like you are behind a NAT firewall so you can make outgoing connections from the DOS PC but you can't easily use it as a server where incoming connections are required.

See the mTCP documentation for details.

GigAHerZ wrote on 2024-09-28, 09:54:

I haven't recently checked - Does the telnet program support Z-modem? There are some telnet BBS'es that don't support X- nor Y-m […]
Show full quote

I haven't recently checked - Does the telnet program support Z-modem? There are some telnet BBS'es that don't support X- nor Y-modem protocol, unfortunately...
Maybe the modem capability can be implemented as a proxy program for packet driver as i think NetDrive has (or will have) the capability? I remember that one reason for lack of z-modem protocol was that telnet binary was getting too big?
All in all, it would be a great addition. 😀

Oh, and another idea, but that might be too much work and not worth it. What about FTP client that mounts the server as a drive? Like NetDrive, but over FTP?
Theoretically, if i understand it correctly, you already have all the bits and pieces for it?

Sorry, no Z-modem. That would make the size of the Telnet program much larger. I'm surprised that there are Telnet BBSes that don't support X or Y modem; that seems to be a configuration error. If there was enough interest I would just have three flavors of Telnet; one with no file transfer, as even X modem and Y modem added quite a bit of code, the current version with X and Y modem, and then a super deluxe version with Z modem too.

I'm not understanding the second part - you want the client side to look like a DOS drive letter, but it speaks FTP under the covers and talks to FTP servers?

mbbrutman wrote on 2024-09-28, 16:58:

I'm not understanding the second part - you want the client side to look like a DOS drive letter, but it speaks FTP under the covers and talks to FTP servers?

Exactly!

GigAHerZ wrote on 2024-09-28, 17:13:

mbbrutman wrote on 2024-09-28, 16:58:

I'm not understanding the second part - you want the client side to look like a DOS drive letter, but it speaks FTP under the covers and talks to FTP servers?

Exactly!

That usecase sounds alot like its covered with Netdrive or alternatively EtherDFS

Yes, it mostly is. Though, having the FTP server set up is slightly smaller one-time cost and there is no need to play around with images - just pure access to files.

I would really like an overwrite option for the FTP server. Something like a FTPSRV_ALLOW_OVERWRITE option in the config file.

I understand for internet connected FTP servers with anonymous access this is not a desired option but I (and I guess most people) only use it internally to update/copy software so it's not really an issue.

In the most recent version I'm still seeing:

1. Very long delays when connecting from a fast machine (e.g. 386+) to a modern Linux FTP server after performing any operation (actual transfer is fast)
2. When using FTPSRV to transfer multiple files (think dozens to hundreds), each subsequent file takes a little longer, until after a while every file transfer, no matter how small, causes the hard drive to thrash violently for quite a while before finally transferring. This is most noticeable on slow machines with MFM hard drives, but it happens everywhere.

It would be neat to make an FTP server look like a drive letter, but under the covers FTP is not a really great match for the way DOS handles drive letters. Which is why protocols like NFS, Samba and EtherDFS exist. It's not something I'm ever going to tackle, although a modern NFS client implementation is certainly possible.

Yoghoo wrote on 2024-09-28, 19:04:

I would really like an overwrite option for the FTP server. Something like a FTPSRV_ALLOW_OVERWRITE option in the config file.

I understand for internet connected FTP servers with anonymous access this is not a desired option but I (and I guess most people) only use it internally to update/copy software so it's not really an issue.

It might not be exactly that, I can probably add a setting with a config file option to set the default for that in this next release.

keenmaster486 wrote on 2024-09-28, 19:40:

In the most recent version I'm still seeing:

1. Very long delays when connecting from a fast machine (e.g. 386+) to a modern Linux FTP server after performing any operation (actual transfer is fast)
2. When using FTPSRV to transfer multiple files (think dozens to hundreds), each subsequent file takes a little longer, until after a while every file transfer, no matter how small, causes the hard drive to thrash violently for quite a while before finally transferring. This is most noticeable on slow machines with MFM hard drives, but it happens everywhere.

Sorry, but nothing I've changed in any of the code would explain that behavior, nor have I seen or heard of that behavior anywhere else.

There some things that you should look at:

• When was the last time you defragmented you hard drive? Fragmented free space would cause similar behavior.
• How old is this hard drive? Is it using a stepper motor or a voice coil? Stepper motor drives in particular need to recalibrate as they warm up, as the heat changes the relative placement of the head to the tracks on the platters. Wear from use also does this too. If it's an old timer you might want to backup and then do a low-level format before things start to become unreadable.
• Did you turn on tracing or something and leave it turned on? Tracing is great for debugging, but it's hard on slower systems.
• Do you have a sufficient number of buffers for DOS in your CONFIG.SYS?
• What have you set the buffer sizes to in the mTCP config file? Specifically FTPSRV_FILEBUFFER_SIZE and FTPSRV_TCPBUFFER_SIZE
• Are you transferring files one at a time or is your client opening multiple connections at a time? Multiple connections at a time is going to slow things down and cause extra work for the hard drive as it juggles the multiple connections.

What you have here is a possible bug report, not a feature request. I really need to see a trace from your system to see what is going on to help you.

Dos . Win16, Win32 server.

I'm sorry, but what are you asking for?

It's a long shot I know, but PC-98 DOS support would be lovely to have someday. The executables start in it but don't work correctly as expected.

I don't have a PC-98 machine to work with.

Can you even get network cards for their bus? If there are network cards, do they have different versions of packet drivers to make them work?

Yoghoo wrote on 2024-09-28, 19:04:

I would really like an overwrite option for the FTP server. Something like a FTPSRV_ALLOW_OVERWRITE option in the config file.

I understand for internet connected FTP servers with anonymous access this is not a desired option but I (and I guess most people) only use it internally to update/copy software so it's not really an issue.

And it is done ... there is a configuration option now that allows you to overwrite files that you are sending to the server. (It is not honored for anonymous users.)

mbbrutman wrote on 2024-09-29, 04:13:

Can you even get network cards for their bus?

There's a ton of C-Bus Ethernet cards and most models from the mid-90s onward have PCI slots too where you could plug in a PCI one. Atm you're basically stuck with Microsoft LAN Manager, Novell Netware, or doing stuff through Windows.

By not working properly I mean stuff like this, which does happen on real hardware as well. I didn't really have any expectations since it's not something you know much about at all, but couldn't hurt to ask I guess.

mbbrutman wrote on 2024-09-28, 20:19:

1. When was the last time you defragmented you hard drive? Fragmented free space would cause similar behavior. 2. How old is th […]
Show full quote

1. When was the last time you defragmented you hard drive? Fragmented free space would cause similar behavior.
2. How old is this hard drive? Is it using a stepper motor or a voice coil? Stepper motor drives in particular need to recalibrate as they warm up, as the heat changes the relative placement of the head to the tracks on the platters. Wear from use also does this too. If it's an old timer you might want to backup and then do a low-level format before things start to become unreadable.
3. Did you turn on tracing or something and leave it turned on? Tracing is great for debugging, but it's hard on slower systems.
4. Do you have a sufficient number of buffers for DOS in your CONFIG.SYS?
5. What have you set the buffer sizes to in the mTCP config file? Specifically FTPSRV_FILEBUFFER_SIZE and FTPSRV_TCPBUFFER_SIZE
6. Are you transferring files one at a time or is your client opening multiple connections at a time? Multiple connections at a time is going to slow things down and cause extra work for the hard drive as it juggles the multiple connections.

Yeah, sorry, I need to get you much more detailed information for this to be useful to you. But these are real problems. I can document everything in a couple of weeks and even take some videos if that would be helpful.

1. Both issues happen consistently for me across multiple machines, fresh installs, over many years. I always use MTCP FTPSRV the most when I'm first setting up a machine, so fragmentation is not a concern.
2. Same answer as #1, happens no matter what drive or machine I'm using, the churning issue even happens on CF cards but it's less noticeable because of the low latency.
3. Nope. But I suppose that would be useful to diagnose the problem.
4. I don't know. I never set the buffers parameter. What should I set it to? I'm a little unfamiliar with how exactly that affects performance.
5. I don't modify these from the defaults. Should I?
6. Single connection. I did think of this already and always set FileZilla to open exactly one connection at a time and transfer files sequentially, which it does. It works great for the first 10-20 files.

Some info off the top of my head that may help:

-All of my machines use 3C509 cards, except for my 5150, which uses some other card... can't remember what it is off the top of my head right now but it's not 3Com
-Always IDE or MFM, never SCSI
-DOS 5.0 on 286- machines, DOS 7.1 on 386+
-Always most noticeable when transferring at least dozens of files a few KB in size, such as for games that have everything split into many small files
-The delay issue (not the churning issue) doesn't seem to happen on slow machines (8088-286)
-My home network is an unremarkable ethernet network with good quality Cat6 cables, recent Netgear router and switches, no WiFi bridges or anything weird like that
-Both issues have happened across multiple modern machines as well, through multiple motherboard and network card swaps, OS reinstalls, etc., so there is no common denominator there