• Please review our updated Terms and Rules here

mTCP 2011-10-01 Release

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,408
This latest release includes the following major changes:

  • IRCjr: Add editing functions in the user input area
  • FTP client: change xfermode to be 'passive' by default for better compatibility with firewalls
  • FTP server: Rewrite directory handling to improve compatibility with more clients
  • FTP server: Fix bug that caused sockets to 'leak' on error paths
  • FTP server: fix MDTM bug that returned the wrong file modification time
  • FTP server: Rewrite screen handling to include a status line and add more console commands
  • FTP server: add addition error detection on the password file
  • FTP server: add configuration parameters for client buffer sizes
  • FTP server: scan for active drive letters at startup
  • other minor bug fixes ...

You can download it from the project page at http://code.google.com/p/mtcp/ . Two versions are available for download: the standard binaries are in mTCP_2011-10-01.zip and the UPX compressed binaries are in mTCP_2011-10-01_upx.zip. The UPX compressed versions take less space on disk but take slightly longer to get running on slower systems. Source code is available on the download page too.


Enjoy!
Mike
 
Hi all,

I found a Telnet options negotiation bug and will probably be doing a small "maintenance" release of mTCP this weekend to get the new code out there.

If you have any bug reports or requests before I do this let me know and I'll see what I can do. I want to keep changes to a minimum but have the best possible code out there for the upcoming FreeDOS 1.1 release.


Mike
 
Mike,
I don't have a bug report for you, but would like to thank you for putting this package out there and for spending so much time supporting it. I use it on all my older PC's, it's very fast and reliable. Now if we could couple you up with the N8VEM group and get these utilities ported to CP/M on a Z80, maybe interfaced with a propeller to ethernet board, life would be wonderful on all fronts. (well all computer fronts...)
Kipp
 
Mike,
I don't have a bug report for you, but would like to thank you for putting this package out there and for spending so much time supporting it. I use it on all my older PC's, it's very fast and reliable. Now if we could couple you up with the N8VEM group and get these utilities ported to CP/M on a Z80, maybe interfaced with a propeller to ethernet board, life would be wonderful on all fronts. (well all computer fronts...)
Kipp

Thanks - it has been a lot of work, but I think it has been well worth it. Personally, I have more excuses to use my old machines now and I almost never have to use "sneaker net" even on my most ancient hardware. Being able to FTP, HTGet, and Telnet around from the old hardware is immensely useful. I think that a lot of other people are making good use of the code, but I rarely hear from them.

The telnet bug is fixed - a test version can be found at http://www.brutman.com/mTCP/telnet.exe .

I am a fan of Andrew Lynch and the N8VEM group in general, but don't have enough time to delve into two architectures simultaneously. I do have a beautiful old TRS-80 Model IV that would be close enough hardware-wise to use for general Z80 work. TCP/IP would be possible, but it would be a stretch. (Others have done it.) To be feasible real Ethernet hardware would have to be available; not just a serial link TCP/IP implementation.



Mike
 
Thanks - it has been a lot of work, but I think it has been well worth it. Personally, I have more excuses to use my old machines now and I almost never have to use "sneaker net" even on my most ancient hardware. Being able to FTP, HTGet, and Telnet around from the old hardware is immensely useful. I think that a lot of other people are making good use of the code, but I rarely hear from them.

Yep, three small files and a network card. That's all it takes to transfer files between almost any machines. I don't bother using anything else now. I recently set up a backup system for my DOS machine and found mFTP transfer rates on files in the 10-100Mb range to be a pretty steady 1030Kb/sec.
 
Last edited:
Awesome piece of software, Mike. :) By the way, I'm curious... How well do you think an XT machine would be able to handle encryption protocols such as SSH and FTP over SSL? Would it be able to even remotely keep up? Has anybody ever tried something like that on 8088/8086 systems?
 
Awesome piece of software, Mike. :) By the way, I'm curious... How well do you think an XT machine would be able to handle encryption protocols such as SSH and FTP over SSL? Would it be able to even remotely keep up? Has anybody ever tried something like that on 8088/8086 systems?

I'm sure it can be done. It's just a matter of how long you want to wait for keystrokes to be echoed. On bulk data transfers it will significantly slow the machine down. Even my fairly well optimized IP checksum routines add quite a bit of overhead.

SSH and other encrypted versions of traditional protocols did not become widespread until the last 5 to 8 years. They are a noticeable drag on older CPUs. On an 8088 it would be nearly crushing.; network latency for keystrokes over telnet is bad enough; doing encryption would make that lag seem longer. And a lot of the algorithms in use (AES) are block ciphers, so you have to encode a group of bytes at a time, not just one.


Mike
 
i've used an SSH client on an 8088 before, it was very slow. of course, mike can probably come up with more efficient software if he tried. i doubt the guy who wrote the one i used was thinking about 8088s and optimizing accordingly.
 
mTCP 2011-10-29: Telnet options negotiation is fixed

mTCP 2011-10-29: Telnet options negotiation is fixed

I released a new version last night. This version fixes the Telnet options negotiation problem; the rest of the code is unchanged.

I committed the sin of not checking return codes when I sent a packet, and I was sending a lot of small packets with telnet options and responses in them. The code just simply ran out of packet buffers to send and without looking at the return code I had no way to know that I was effectively throwing data away. Telnet sites like sdf.org and thekeep.net should work perfectly now on a variety of machines and under different timing conditions.

I intend this to be the last release for a while, unless I get a really really good idea.

There is a lot of existing DOS networking software out there, including SSH and RSYNC. Most of these work fine on a faster machine, and only become painful on the slower machines. Some require DOS extenders to make use of more RAM and will never be usable on 8088 class machine.

If you have a pet program that you'd like to see, find the source code and lets talk about it. A lot of code can be improved as is by finding the portions of the code where it spends a lot of time and optimizing/rewriting just those portions. If you are being gated by the speed of the network code (Watcom) porting to mTCP is possible too.


Mike
 
i've used an SSH client on an 8088 before, it was very slow. of course, mike can probably come up with more efficient software if he tried. i doubt the guy who wrote the one i used was thinking about 8088s and optimizing accordingly.

Mike has done a good job with the software- I put it on every vintage machine I work on, and it works fine even on my 5150. I do think it would be nice to see "mTCP SSH" or "mTCP SFTP" if only because some servers (including my university) will actively refuse unencrypted connections without a VPN; I have found the WATTCP version of SSH (real mode) to be extremely unreliable on either an 8088 or 286.
 
Thanks for this Mike! mTCP exponentially increases the fun factor of playing around with these old machines, very cool stuff. I've had your software successfully running on an XT 5160 with a WD8003E, 3C503, and NE1000 ... accessing my Gmail over telnet, FTP'ing versions of DOS and CP/M on down to the XT's 10MB hard drive, running FTP servers from a 5.25" floppy disk, serving up files to my iPhone, talking to my DOSBox ...
 
You are welcome ...

In the time since my last mTCP update FreeDOS 1.1 was released and it formally included mTCP in the install image. Everybody seems pretty happy to have some newer/updated networking code to use as the existing code was getting very stale. If you can think of ideas to improve it or new applications, let me know. Here is the current todo list:

  • More intelligent time-out and retransmit code
  • IPv6 (longer term)
  • more ICMP message support


Mike
 
If the packet driver specification allows it, I'd like the ability to put the interface into promiscuous mode and just dump in both hex and ascii every packet the card can see over the wire, realtime. I was trying to troubleshoot DHCP.EXE last night and it would have been cool to see what the card saw(*).

Essentially, something like Solaris snoop or Linux tcpdump.

I would have written it myself except that I still haven't solved the problem of how to call watcom libraries from a non-C language :) That's a project down the road. I would personally like to write all sorts of completely impractical things using mTCP, like a VNC viewer or Remote Desktop client (which might have to be limited to a 640x480x256 or 800x600x256 desktop, but it should be possible).

(*) It turns out it wasn't mTCP's fault, it was the card. The diagnostics sort-of passed, the packet driver initialized, link light was on, full duplex, etc. but the card wasn't receiving packets properly. I am working with a slightly dodgy PC compatible, an AT&T PC 6300, and the bus timings on that machine make it somewhat incompatible with about half of all ISA cards ever produced. I was trying to use a Linksys Ether16. I'll test it in another machine tonight to verify if it's the card or not. The Intel Etherexpress LAN 8/16 should work (I have one in my XT) so I have another one coming in the mail in a few days to test it out.

MOV [rant],1
It's hard finding ISA cards that work in an 8-bit slot with a native RJ45/UTP interface. I hate AUI dongles with a passion and refuse to use or collect them. I found a batch of NOS Intel Etherexpress Pro 10+ cards last night (10 for $8!) and almost ordered them but 30 minutes of research confirmed they don't work properly without a true 16-bit slot, so I dodged a bullet there.
MOV [rant],0
 
MOV [rant],1
It's hard finding ISA cards that work in an 8-bit slot with a native RJ45/UTP interface. I hate AUI dongles with a passion and refuse to use or collect them. I found a batch of NOS Intel Etherexpress Pro 10+ cards last night (10 for $8!) and almost ordered them but 30 minutes of research confirmed they don't work properly without a true 16-bit slot, so I dodged a bullet there.
MOV [rant],0

Why the hate towards them? They have always worked fine for me, what issues are you experiencing?
 
Why the hate towards them? They have always worked fine for me, what issues are you experiencing?

Perhaps it is because they are not 8 bit. However, I would like to say that for 16 bit, this is the best card ever - simply because it has the smallest and fastest driver of any that I've found. The Crynwr LAN595.COM driver is about 8K and doesn't hang for a second figuring out what it's going to do, like some other drivers. I had to replace mine with a PCI card because of lack of available ISA slots in my DOS "power box", and it still irks me that I can't find a small, or fast loading, PCI driver for any card. The Intel Etherexpress Pro 10+ is still the ultimate - unless you want 8 bit of course, in which case it is useless.
 
Trixter,

I started on a diagnostic utility for exactly that type of problem. I really should dust it off and finish it. 'TCPdump' is basically built into each program - that's what you are triggering when you set the debug level in the environment variable. There is a more complete packet dumping utility that operates as a shim between the application and the real packet driver, but that is more complicated to setup and it doesn't do anything to interpret the packets.

The promiscuous mode question is a good one - I don't know how to do it! Based on what I read some cards are always in promiscuous mode, and you use a -p option on the packet driver to suppress it. I've sent off an email to the originator of the packet specification and I'm hoping for a reply. (He's been good about that in the past.)

I'd like to see a VNC or remote desktop client, but those definitely are not for CGA. I'm too lazy to learn how to do VGA programming myself though. ; - 0

There was another user I haven't seen post in a while - Wiwa64. He had some lower level sniffing and traffic viewing utilities that are ready to run today. I'm not sure how he addressed the promiscuous mode question though. Look for his handle and you can find his utilities. (They are WATTCP based.)
 
Why the hate towards them? They have always worked fine for me, what issues are you experiencing?
Despite being a great solution for retrocomputing, as most of them work fine in an 8-bit slot, I can't stand the dongles sticking out the back. I've snapped them off more than once even when I was being careful, destroying both dongle and card; the last straw was when I bent a case frame doing that. So, no more. I stopped collecting them a decade ago and threw out all I had except for one (extremely rare card, name escapes me, functional in an 8-bit slot).

mbbrutman said:
IPv6 (longer term)

Whoa, is this possible with the existing packet driver spec? (thinking) I guess it would be, since you're just getting raw datagrams over the wire. Wow, ipv6 is something I've never played with but that would be really neat in a few years.

mbbrutman said:
I'd like to see a VNC or remote desktop client, but those definitely are not for CGA. I'm too lazy to learn how to do VGA programming myself though. ;-0
You're putting too much serious thought into it -- it's a silly project, but that has never stopped me. For example, if the vnc server was limited to an 8-bit (256-color) desktop, it would be trivial to implement on the DOS client by allocating 640x480 bytes in a single linear buffer, which translates to a 640x480x256 screen. Then just blit a 320x200 section of that buffer to the screen, ie. a "window" to the full buffer. I would deal with CGA colors by mapping them to a 4-color grayscale and just use the cyan-magenta-white palette with black background and treat it as grayscale, which would make black text on white background perfectly readable. These are really fast conversions to do; one frame per second has got to be possible on the slowest 8088, maybe faster if delta handling is intelligent.

As for VGA or VESA, those are easy since you don't have to do any color conversion. In fact, it would take the challenge out of writing a VNC viewer for DOS -- too easy.

I'm curious what the crynwr guy says about promiscuous mode.
 
If the packet driver specification allows it, I'd like the ability to put the interface into promiscuous mode and just dump in both hex and ascii every packet the card can see over the wire, realtime. I was trying to troubleshoot DHCP.EXE last night and it would have been cool to see what the card saw(*).

Essentially, something like Solaris snoop or Linux tcpdump.
You might possibly want to have al look at the ETHTOOLS package which is available here: http://www.bttr-software.de/products/jhoffmann/
 
You might possibly want to have al look at the ETHTOOLS package which is available here: http://www.bttr-software.de/products/jhoffmann/

That actually fits the bill :) I wouldn't dare to stop Mike from making an mTCP variant, but Mike, if you want to, grab the ETHTOOLS package since it comes with C source and might answer your promiscuous mode questions.

(OT: The card I ordered isn't going to work either. Although it works fine in my XT, I saw this on the Intel website:

AT&T 6300 AND 6300+ EtherExpress 16 Family
Product: EtherExpress 16 and 16TP adapter Compatibility: Incompatible
Customer reports that the AT&T 6300 and 6300+ are incompatible with the EtherExpress Cards. The AT&T 6300 and 6300+ are not 100% IBM compatible machine.

I'm now combing through every spare ISA network card I have trying to find one that will work, including some cards I can't identify. Maybe I *will* end up getting another damn AUI card... and there's always the Xircom, although I was hoping to keep my parallel port hooked up to my printer.)

Okay, sorry to hijack the thread, back to mTCP talk. I am serious about the VNC viewer; if no compression is used and only uncompressed deltas are sent over the network, it should be possible to do on 808x machines. I talked to one of the OpenWatcom people a few months back and he said it was fairly easy to call Watcom-compiled libraries from assembler, so maybe I'll start there after my benchmark tool is finished.
 
i've been seriously thinking about doing a new DOS VNC client myself! i did one ages ago in QuickBASIC (must have been 6-7 years ago?) but now that i'm past that QB crap, i've been thinking of giving it a go with C and assembly. it is most definitely do-able on an 8088, yes.

Whoa, is this possible with the existing packet driver spec? (thinking) I guess it would be, since you're just getting raw datagrams over the wire. Wow, ipv6 is something I've never played with but that would be really neat in a few years.

yes, definitely can do IPv6 with packet driver.
 
Last edited:
Back
Top