This is what it is. Is it supposed to be something different? How/where can i generate something you have brought as an example?

Mike is probably going to refer you to his documentation, which contains an overview of the TZ variable in the SNTP section, as well as a link to another PDF with the full syntax

As was foretold by the prophecy ... start with the manual here: http://brutman.com/mTCP/mTCP_2020-03-07.pdf

FTP and HTGET are nice, but they can not get to modern links or servers, today everything is using SSL/TLS.

Or maybe someone would sugest a free (semifree with limited space, we do not need mutch for our retrocomputing needs) FTP hosting service that can be accessed with IPv4 and plain FTP.

@Cyberdyne: not sure if you got the scope of "mTCP" right. As it's meant for retro systems, I guess it's not the option for communicating with modern links or servers (outside your retro LAN)

Cyberdyne wrote on 2020-12-30, 06:03:

FTP and HTGET are nice, but they can not get to modern links or servers, today everything is using SSL/TLS.

Or maybe someone would sugest a free (semifree with limited space, we do not need mutch for our retrocomputing needs) FTP hosting service that can be accessed with IPv4 and plain FTP.

You can always set up a local VM that serves resources for retro stuff in local network.
I have a Debian VM, that "proxies" SMB3 shares forward as FTP and SMB1 shares. This way, i don't have to make my main infrastructure unsecure, while at the same time, when i start VM, i have those resources available for retro stuff.

I really do not want to be critical. It is nice stuff. But if it does not communicate with outer world. It is more compatible to use Novell stuff, IPX/SPX.

Or that dos virtual hard drive plus linux computer thingy.

Everything outside your retro-whitebox is "outside world" for it.

You are not going to get your 386 to browse SSL encrypted HTTPS websites either... Too bad, nothing to do about that.

GigAHerZ wrote on 2020-12-30, 12:00:

Everything outside your retro-whitebox is "outside world" for it.

You are not going to get your 386 to browse SSL encrypted HTTPS websites either... Too bad, nothing to do about that.

Never say never. There is always a way to do something.

Two ways to do this:

A proxy such as WebOne
Up-to-date browsers such as Links

What is the scope of mTCP? I chose TCP/IP because it is the open protocol of choice for any machine to use. It is not just about simple printer and file sharing. Telnet and FTP can take you anywhere the Internet is, no matter what that machine is. You can choose to use it on your own home network or you can branch outside to wherever. Just don't try to use it for online banking. ;-0

There are plenty of open FTP servers still out there. ftp.oldskool.org in particular is a fantastic resource. SDF.org provides a free Unix shell account via telnet. There are too many Telnet BBSes to enumerate here.

People can also make some small changes to keep their web sites accessible for retro machines. Case in point: brutman.com has both HTTP and HTTPS support for static content where no passwords are exchanged, making all of that content accessible to vintage machines. I insist on the PCjr forum using HTTPS because passwords/cookies are being transmitted there. But there is no reason for static content to be HTTPS only.

mTCP has both an FTP server and an HTTP server that you can use to hold content on the open web.

The encrypted web is generally a good thing. But if you want to keep the old hardware interesting and usable, put up servers like oldskool.org that don't need or require encryption. And even if you do telnet to something that is insecure, don't reuse your passwords ... that is good advice no matter what you are doing.

As some point we'll have to use proxies to strip the encryption from protected content. But we are a long way from that, and there is a lot of non-encrypted content out there.

Just wanted to say a huge thanks for your work mbbrutman. I entered the world of retro networking for the first time this week. You've made it obscenely simple to get things going, and I don't think I'll run a non-networked DOS machine again. The FTP server in particular has changed everything.

Pierre32 - thank you. It has been a great project and I'm happy that people are enjoying it.

I'm also a devout disciple of MTCP 😀

One of the first things to go into my retro builds is a network card and the MTCP programs. I often set up my entire disk drive as an FTP server and then easily copy everything in the right place from my modern machine.

This has saved me countless hours of floppy disk swapping or CD burning.

Hezus wrote on 2021-01-06, 09:21:

I'm also a devout disciple of MTCP 😀

One of the first things to go into my retro builds is a network card and the MTCP programs. I often set up my entire disk drive as an FTP server and then easily copy everything in the right place from my modern machine.

This has saved me countless hours of floppy disk swapping or CD burning.

I do exactly the same. mTCP suite just makes everything easier.

I've found some performance problem in the FTP client in recent mTCP versions...

The client machine:

386DX-40
3C515 using ODI driver + ODIPKT.COM

The server is a modern machine running Linux.

All tests done transferring a 10 MB file in BINARY mode.
All numbers in KBytes/s.

Jul 5 2015

download to HDD: 336
upload from HDD: 487
download to RAMdrive: 560
upload from RAMdrive: 648

Jan 1 2020

download to HDD: 98
upload from HDD: 476
download to RAMdrive: 113
upload from RAMdrive: 620

Mar 7 2020

download to HDD: 97
upload from HDD: 471
download to RAMdrive: 113
upload from RAMdrive: 614

Something in the download got broken between 2015 and 2020...

Interesting, but I suspect it is related to your packet driver setup.

On my 386-40 I get the following:

2015 code: 526.3 KB/sec sending and 543.6 KB/sec receiving
2020 code: 464.5 KB/sec sending and 485.2 KB/sec receiving

(All tests are with a 16K TCP buffer and a 16K file buffer)

So it is slower, but I think I know the problem - I moved from direct screen writes for the progress indicator to BIOS calls. I'll confirm that later by removing the file progress indicator.

The raw TCP/IP socket performance is:

2015 code: 690.9KB/sec sending, 957.0KB/sec receiving
2020 code: 702.0KB/sec sending, 1001.8KB/sec receiving

So the libraries are about equivalent; it's the file I/O or screen writes that care causing the slowdown in the FTP client.

For your specific machine - Can you send me a debug trace? Before you run an FTP transfer that you know is going to be slow:

• SET LOGFILE=FTPTRACE.LOG
• SET DEBUGGING=1

That should give me the warning messages only, which won't slow things down. If I need more details after seeing that I'll let you know.

Mike

Does this change also affect the FTP server?

mbbrutman wrote on 2021-02-16, 20:53:

Interesting, but I suspect it is related to your packet driver setup.

Well, yes, it *is* a special setup - one of those elusive 100 Mbps ISA cards, with no native packet driver, therefore the need for the ODI shim.
Nevertheless, it all works fine with the 2015 version.

For your specific machine - Can you send me a debug trace? Before you run an FTP transfer that you know is going to be slow: […]
Show full quote

For your specific machine - Can you send me a debug trace? Before you run an FTP transfer that you know is going to be slow:

• SET LOGFILE=FTPTRACE.LOG
• SET DEBUGGING=1

See the attachment.

Also, I tried to do the SPDTEST tests:

spdtest -send -listen 2000 -mb 8
time nc 192.168.2.100 2000 -q 0 > bogus.bin
spdtest -receive -listen 2000
time nc 192.168.2.100 2000 -q 0< bogus.bin

Turned out that my version of nc doesn't support the "-q 0" option, so it doesn't exit after the transfer - all the results below are from the DOS side.
Also, the 2015 version of SPDTEST hangs after the transfer, but it does display the result before hanging.
The 2020 version of SPDTEST works OK.

Jul 5 2015

send: 23.389..24.423 s
receive: 9.934..9.945 s

Mar 7 2020

send: 24.406..24.411 s
receive: 9.944..9.945 s

Indeed, no important differences between both versions here.
But there's one weird thing... the speeds would be about:

send: 335 KB/s - much less than FTP upload!
receive: 825 KB/s

keropi wrote on 2021-02-16, 22:52:

Does this change also affect the FTP server?

I haven't tried the FTPSRV.

FTPSRV is not be affected by the change to use the BIOS calls for updating file transfer progress.