• Please review our updated Terms and Rules here

mTCP 2013-04-26 is available

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,417
And nearly another year has passed by ...

This version includes:

  • All: improved TCP/IP lost packet and retransmit support
  • All: DHCP lease expiration detection and warning
  • IRCjr: mIRC color codes, improved logging support, 132 column awareness, bug fixes
  • FTP client: user input can be longer now (2 lines), 125 responses handled better
  • FTP server: improved compatibility with more clients.
  • Telnet: improved emulation (scroll regions and origin mode support)
  • Many other small fixes and improvements ...

Everything is available at http://code.google.com/p/mtcp/ . Documentation and screen shots can be found at http://www.brutman.com/mTCP/ .


Enjoy!
Mike
 
Just a warning - a user reported to me that Netcat was not working correctly in this version. It turned out to be a build script problem. Nothing else was affected.

I have placed a new version of the executables on the web site with a new version number. Please update if you use Netcat or ever thing you might want to use it.

My apologies go out to anybody who was caught by this. I try to test everything using the same Zip files that I make available for download to others, but I missed this one.
 
Hi, thank you for this cool package. It is really fun have XT act as ftp server. I am seeing slight problem. When using WIN XT as peer (gateway to internet, ftp client ..) the link seems to be really slow.

Pinging 192.168.0.210 with 32 bytes of data:

Request timed out.
Reply from 192.168.0.210: bytes=32 time=3ms TTL=255
Request timed out.
Reply from 192.168.0.210: bytes=32 time=4ms TTL=255

Ping statistics for 192.168.0.210:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 4ms, Average = 3ms

Sometimes it impossible to log in ftpsrv.
C:\>ftp 192.168.0.210
Connected to 192.168.0.210.
220 mTCP FTP Server
User (192.168.0.210:(none)): ftp
Connection closed by remote host.

When in Linux on the same PC there are no problems at all. What direction should I investigate the problem ?
 
So it's flawless when you use a Linux client to the XT, but it is dropping packets when you use XP as the client?

The lost packets are a very bad thing and are the cause of your problem. Do the XP machine and Linux machine get the same address from the DHCP server? Is there another machine on the network that might be using that IP address too? Is there some dodgy equipment between the two machines?
 
Hi, only these two machines (modern double boot PC and XT) are connected via crossed cable. The double boot XP/Linux PC has a WiFi card too. I am using it as gateway to internet for the XT. WiFi AP with 5-port hub is downstairs way too far for any cable. Yes it seems dropping packets when using Windows XP. I installed some DHCP server on the Windows XP. As soon as I boot Linux on it, the same hardware setup works flawlessly. I will investigate it further. Maybe install another DHCP server on XP. The problem is, I want XT on internet to be able to use sntp. And because these machines are only within WiFi reach I need to use the other one as gateway. I do not want drill walls and lay cables to connect XT to hub with cable.
 
I was going to suggest the cross-over cable, but that is more of an advanced debugging topic.

Most mTCP programs will tell you if they had to retransmit lost packets. This happens at the end, or it will be in the trace if you turn on minimal tracing. (See DEBUG.TXT.) Are you sure that no packets are being lost when using Linux? The statistics from the mTCP side would be helpful so you can compare against XP and Linux.

I really doubt that XP is the problem. But you've already eliminated the network as a problem.
 
Hi, I moved the XT downstairs, connected it to HUB. It is there on since two hours. Trying ftp from here upstairs or ping works fine over wifi since then. So that means XT is fine. I was wrong, Linux is having the same difficulties. I did not test it long enough before probably. I will have to elaborate on modern PC. Maybe gigabyte LAN is too fast :) Thanks for help and really cool networking suite.
 
Last edited:
Hi, I bought a cheap TP Link PCI card, installed it the PC with Linux/Windows. Expectably it works now without any lost packets. I think integrated ethernet chip is dying on the motherboard.
 
mbbrutman said:
Just a warning - a user reported to me that Netcat was not working correctly in this version. It turned out to be a build script problem. Nothing else was affected.

I have placed a new version of the executables on the web site with a new version number. Please update if you use Netcat or ever thing you might want to use it.

My apologies go out to anybody who was caught by this. I try to test everything using the same Zip files that I make available for download to others, but I missed this one.
Click to expand...

3000+ downloads later ...


W00t!



Mike
 
I just grabbed it last night and put it on a Pentium 120 that I wanted to populate in a hurry. Easily one of the top three "most useful" homebrew software I've ever used.
 
4000+ downloads now!

(And probably a few more given that it is also mirrored at ibiblio.)


Mike
 
I'm not sure if this is a bug report or a fluke on my end, but yesterday I was about to use the ftp client to a local PC. For some reason, I had "SHIFT LOCK" enabled, so the top row of numbers were all shifted and I accidentally tried to "ftp $$". It caused the client/computer to hang. I might still be using a slightly older version, and I didn't try to replicate the behavior, so feel free to dismiss this as an irrelevant message if you already are certain that the argument handling is fool proof and should exit with an error message for arguments that don't make up IP addresses or legal hostnames.
 
carlsson said:
I'm not sure if this is a bug report or a fluke on my end, but yesterday I was about to use the ftp client to a local PC. For some reason, I had "SHIFT LOCK" enabled, so the top row of numbers were all shifted and I accidentally tried to "ftp $$". It caused the client/computer to hang. I might still be using a slightly older version, and I didn't try to replicate the behavior, so feel free to dismiss this as an irrelevant message if you already are certain that the argument handling is fool proof and should exit with an error message for arguments that don't make up IP addresses or legal hostnames.
Click to expand...

Anything is possible but I just tried it in DOSBox and VirtualBox here and it tried to resolve a bogus IP address, but it did not hang the machine up. The DNS request got passed through as expected and came back as not resolvable.

What mTCP version and what version of DOS do you have?
 
You must log in or register to reply here.
Back
Top