Just a question, how hard is to implement modern SSl and HTTPS and modern secure FTP. It is a nice software, but i reality, you can not retrive aniything from the wild.

On 16 bit machines it is not feasible. Even if all of the current library support was available right now, it would be too slow and it's a moving target that would be obsolete in 3 years.

The best options are:

• Start equipping old machines with Raspberry Pi Zeros to serve as crypto coprocessors. (Pi Zeros are cheap, but it would take some work to integrate them onto a machine.)
• Encourage and support sites that continue to keep HTTP and FTP available.
• Use a proxy service that can strip SSL for HTTP traffic. (Assuming the data is not sensitive.)

Great software! As requested some wish list items:

• An overwrite option for ftp uploads. So overwrite a file if it already exists.
• Break off option for long filenames (so only keep the first 8 characters of a filename if it exceeds that limit).

Don't know if it's possible but these 2 items are what I manually have to fix very often. 😀 At the moment the upload is hanging for 10 seconds or so if one of those things (filename too long or file exists) happen after which it will error out.

(Yoghoo - my apologies for missing your post the last time around!)

It's that time again! I'm getting ready to roll up a few bug fixes into a new release so please send me your bug reports and wish list items. (I'll also be going through the older wish list items too.)

The next release will have the following:

• Telnet: RLE graphics support
• Telnet: A work-around for an invalid ESC sequence being sent by Linux systems when setting the scroll region.
• DHCP: Formalizing the work-around for bad routers that don't respond with the assigned hostname.
• HTGet: set the file timestamp when saving the output to a file
• HTTPServ: provide a version that uses BIOS screen writes for use with DESQView
• TCP library: Bug fix for machines using Explicit Congestion Notification

And the big change is Unicode support in IRCjr and Telnet, for both sending and receiving. No more "mojibake" on the screen when somebody sends you UTF-8. And if you have a European layout keyboard or need proper accented letters then you'll want this update.

I don't have any bug reports or feature suggestions, just wanted to say thanks for creating this excellent program! The FTP server component makes transferring files to and from my DOS machine extremely easy.

In particular, I like how I can set up a simple .BAT file which starts the network card's packet driver, then sets the mTCP config variable, runs the DHCP component and lastly starts the FTP server component. That way, there's no need to allocate any resources to the network if all I want to do is play games. But when I do need to transfer some files, I just have to run a single .BAT file and everything is good to go. Awesome stuff!

As I heavily use mTCP for testing NICs and other network equipment, my wish list is:
-a Audible ping.

Also, sometimes I need to ping a DOS host from outside, so I do "nc -listen 666" to make it respond.
But the problem is: sometimes I'm limited to a diskette, and with minimum DOS, a bunch of NIC drivers, and other essential stuff, there's only room for minimum mTCP: DHCP, FTP, PING, and the config.
So, how about adding "listener mode" to PING ?

BTW: consider renaming "NC.EXE" to "NCAT.EXE", as "NC" clashes with Norton Commander. Also, in Linux, "nc" is just a symlink to "ncat".

Grzyb

• Are you using the UPX encoded versions of the binaries? The UPX encoded versions of those take up 116K of space compared to 193K for the normal versions.
• Re Netcat's name: I'm not going to try to pick names that don't conflict with other well known programs because I can't satisfy that requirement reasonably for everybody. I think renaming the file locally to what you need for your system makes the most sense. I am very careful to make sure that none of the code ever assumes a default file or file path because of the potential for conflicts.
• Re Audible ping: Can you elaborate? Make a noise when a response is received?
• Re Ping listen mode: That's an interesting use case. Netcat works well for it because Netcat is designed to be either a client (initiator of a connection) or a server (recipient of an inbound connection). Ping traditionally is always a client, so it doesn't make sense for it to have a listen mode. Would adding a 'beep on packet receive' type option work for PKTTOOL instead? It would beep for every incoming packet regardless of the IP address.

Joseph_Joestar wrote on 2023-02-05, 07:33:

I don't have any bug reports or feature suggestions, just wanted to say thanks for creating this excellent program! The FTP server component makes transferring files to and from my DOS machine extremely easy.

Thanks .. that's one of the goals. I'm also quite happy using IRC and Telnet on my vintage hardware too. And don't forget, you can easily run a web server on an old 286 - http://floppy.museum/ runs on a 286-12.

One day I'll have enough hardware and software to be able to sell cloud services run on XT class hardware. ;-0

mbbrutman wrote on 2023-02-05, 17:22:

[*]Are you using the UPX encoded versions of the binaries? The UPX encoded versions of those take up 116K of space compared to 193K for the normal versions.

Sure, and I use UPX for other programs as well, nevertheless 1.44 MB is often not enough...

[*]Re Audible ping: Can you elaborate? Make a noise when a response is received?

Exactly.
Try this on Linux: ping -a 127.0.0.1
(make sure your terminal properly supports the bell)

[*]Re Ping listen mode: That's an interesting use case. Netcat works well for it because Netcat is designed to be either a client (initiator of a connection) or a server (recipient of an inbound connection). Ping traditionally is always a client, so it doesn't make sense for it to have a listen mode. Would adding a 'beep on packet receive' type option work for PKTTOOL instead? It would beep for every incoming packet regardless of the IP address.

That's not what I meant.

I don't want any software running in listen mode to beep.
I want an option for PING to beep in client mode.

Also, I want a program for DOS that listens for ICMP ECHO_REQUEST, and replies with ECHO_RESPONSE.
Netcat works fine, but occupies 46 KB, so I want to avoid keeping it on my diagnostics diskette.
PING occupies 28 KB, and is a must-have anyway, so I'm wondering about feasibility of adding the listen mode to PING...
obviously, some ICMP code is already there in PING.EXE, therefore hopefully adding the listen mode would be easy and wouldn't cause the EXE to grow a lot...

I would like to thank you for this nifty utility. I have two suggestions when using the FTP server and client:

• It is possible to keep the actual timestamp when transferring files?
• Could LFN support be implemented? It is to avoid renaming each file into to the 8.3 format.

Grzyb,

Audible ping is easy. I'm not convinced that a "listen mode" ping is worth the time to create and maintain going forward, especially since netcat in listen mode already basically does what you are asking. I'll add it to the list of possible features but it's not going to be near the top of the list.

[Edit] Audible ping is done ...

Gmlb256,

Preserving the timestamps on files in FTP makes a file transfer more complicated, as getting the timestamp is a whole separate FTP command from getting the file. It's on the list because it's useful, but it's also painful to implement.

My hesitation around DOSLFN is that I need the same programs to work on DOS 2.1 all the way to the newest versions. It's also a lot of rip-up in the code; I put a lot of effort into validating paths and filenames to keep things safe and avoid surprises due to bad input, and just ripping that code out can expose people to some pretty bad side effects.

I would suggest implementing an auto LFN to 8.3 conversion in the FTP server. If the connected client tries to PUT a file with a LFN currently it just fails. You could make it simply write the file to disk in the truncated name format like win9x did. blahbl~1.exe

+1 for timestamps

I'm wondering if you could implement a screen blanking/simple screensaver function in both FTPSRV and HTTPSERV? Of course, I could always turn off my monitor when I walk away from my own PC but that may not be possible for some clients with integrated CRTs with no separate power controls from the rest of the machine (old AIOs and luggables such as the Compaq Presario 425 and Portable come to mind). Thank you for this great software by the way!

Hi GulchWinder3D,

Try looking for a TSR utility that does this - there were many of them, and they don't take a lot of RAM. (I used one for my AT back in the day.)

And +1 to using a screen blanker to protect your phosphors or save energy. The PCjr is up and running over 90 hours now (http://brutmanlabs.org/) and I would never think of leaving a monitor on for that long. I have a different trick to monitor it though - remote logging. 😀

-Mike

I'm thinking about possibilities of LFN support in the FTP client...
- not really necessary with GET, as it's possible to specify different remote and local names
- very useful with MGET

But how exactly should it work?

I think it doesn't make sense to support stuff like DOSLFN - I doubt if any of such utilities is reliable enough for normal use.

So, the names need to be converted to the 8.3 format:

longfilename.html -> longfile.htm
longfilename.tar.gz -> longfile.gz
.bash_history -> bash_his

...and then what?

Currently, FTP client silently overwrites existing files when downloading files of the same name, and it's OK.
But that probably wouldn't be the preferred behavior with auto-truncated names...
- with PROMPT ON, I think it would be acceptable to ask the user whether to overwrite or rename
- with PROMPT OFF, however, can't ask the user... so, auto-rename all the clashing names?

longfilename1.zip -> longfile.zip
longfilename2.zip -> longfil1.zip
longfilename3.zip -> longfil2.zip

These are just my thoughts on that matter, I'm not claiming it's the only way to go...

I'm bogged down with the web server at the moment. It crashes after a few days or weeks and it's really hard to tell why; I know there is a hardware problem probably with the IDE controller, but I'd like to figure out if I have a software problem too.

Your post got me thinking about user interface design. I usually choose a design that offers the least surprises. Based on that, overwriting files without prompting is probably not a good design and that should be fixed. (I think traditional FTP clients have a "clobber" or "noclobber" setting.)

I did "mget *", several times, in the following FTP clients:
- the one from modern Linux
- the one from Windows 98SE
- CUTCP, FTP version 2.2/TC-Rutgers-1.0
- Waterloo TCP, FTP Transfer Program Version 0.70

Linux, Windows, CUTCP: existing files are silently overwritten
Waterloo: prompts user whether to overwrite or skip, even with PROMPT OFF, and there's no option to rename

There's no CLOBBER/NOCLOBBER setting in any of the above clients.

Conclusion: there's no surprise about overwriting files without prompting - majority of clients behave this way.

Now, what the DOS clients do when mgetting these:

verylongname1.txt
verylongname2.txt
verylongname3.txt
verylongname4.txt
verylongname5.txt

CUTCP: shorten everything to "verylong.txt", and overwrite
Waterloo: shorten everything to "verylong.txt", and prompt user whether to overwrite or skip

Conclusion: it's perfectly OK to shorten long names to 8.3, and not care about files getting overwritten.
And I think it's better than the current behavior of the mTCP client, ie. always skipping the files with long names.

But we want mTCP to be better than CUTCP and Waterloo, right?
So, there's this option in the Linux client:

1     runique     Toggle storing of files on the local system with unique file‐
2                 names.  If a file already exists with a name equal to the
3                 target local filename for a get or mget command, a ".1" is
4                 appended to the name.  If the resulting name matches another
5                 existing file, a ".2" is appended to the original name.  If
6                 this process continues up to ".99", an error message is
7                 printed, and the transfer does not take place.  The generated
8                 unique filename will be reported.  Note that runique will not
9                 affect local files generated from a shell command (see
10                 below).  The default value is off.

Probably the most elegant solution...
of course, can't append ".1" to ".99" in DOS, so instead:

longname.ext
longnam1.ext
longnam2.ext
...
longna99.ext

Also, there's one more option in Linux, Windows, CUTCP clients that I could use in the mTCP as well:

1     bell        Arrange that a bell be sounded after each file transfer com‐
2                 mand is completed.

Ah, it was lftp that has the xfer:clobber option that can be set to allow overwriting of files.

I could see doing something like runique in the future.

Just in case you did not see the news elsewhere, the new mTCP is finally available. Here is what you can look forward to:

• Unicode support for Telnet and IRCjr
• A fix/workaround for the badly behaved DHCP servers that were not sending the HOSTNAME option.
• RLE graphics in Telnet, which is useless but fun.
• An SNTP client in the web server for those multi-day or mult-week web serving sessions.
• Bug fixes and small improvements sprinkled throughout the code.

The release notes and downloads can be found at http://www.brutman.com/mTCP/mTCP.html

At the moment those pages are being redirected from my normal web server in the cloud somewhere to a PCjr in my home office. The PCjr is on a UPS; I want to see how many weeks it will stay running. (My previous record was five weeks before a suspected hardware problem required me to shut it down.) If you want to visit the machine directly to see the uptime statistics head over to http://brutmanlabs.org/ .

-Mike