• Please review our updated Terms and Rules here

It's that time again: send me your mTCP bug reports before the next release!

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,418
If you have found a possible bug in mTCP I'd like to hear about it now before the next release. Please post here for general wish list items, and for possible bugs please email me directly.

So far the next release will have:
  • TCP flow control fixes for even better compatibility and behavior on slow connections
  • A UDP fix. (Repeat after me .. Checksums are optional. Checksums are optional.)
  • Broadcast Ping
  • A more accurate SNTP client
  • HTTPServ: proper support for index.htm files and some minor bug fixes.
  • Proper HOSTS.TXT type support
  • DNS workaround that fixes DNS on "WiFi" modems using NAT/SLIP (*) read more below
There will probably be some other small fixes too.

(*) A side note on WiFi modems: a lot of people are using them as a way to do serial other the network. Over at TheOldNet.com Rich figured out that the ESP8266 can run a different firmware that has you use SLIP to talk to the ESP8266, then goes through a NAT layer to get on the network. In English that means these devices can put any computer capable of running a SLIP connection on the network via the serial port.

I've done it now with both a new Linux machine and a 386-40 running mTCP. While getting an old machine on the network as a terminal is neat, running TCP/IP natively is still better. 😀 That alternative firmware is not perfect but it is usable as-is right now and it has a lot of potential.

Mike
 
I would love to see a telnet serving TSR that emulates a com port. Working for incoming and outgoing connections would be even better. Exactly what a Wifi modem does, but without the extra hardware for us folk with 10baseT already running to the machine.
 
TheDrip said:
I would love to see a telnet serving TSR that emulates a com port. Working for incoming and outgoing connections would be even better. Exactly what a Wifi modem does, but without the extra hardware for us folk with 10baseT already running to the machine.
Click to expand...
Do you realize intercepting writes to port is only possible in virtual 86 mode on 386 and higher. That's completely useless for XT and 286 computers.
 
mbbrutman said:
I've done it now with both a new Linux machine and a 386-40 running mTCP. While getting an old machine on the network as a terminal is neat, running TCP/IP natively is still better. 😀 That alternative firmware is not perfect but it is usable as-is right now and it has a lot of potential.
Click to expand...

On one hand I want to agree that, yeah, it’s cool there’s a solution brewing for ”real” TCP/IP via one of those wireless serial dinguses, but… man, I was so happy with how much better the mTCP programs worked on my Tandy 1000 EX/HX after going through the agony of wedging Ethernet cards into them vs. PPP or SLIP to a Linux box. Even with a 16550 UART the overhead is murder on such slow machines. (On a 386, sure, it’s probably fine.)
 
dhau said:
Do you realize intercepting writes to port is only possible in virtual 86 mode on 386 and higher. That's completely useless for XT and 286 computers.
Click to expand...
I did not know that. There goes my dream.
 
dhau said:
Do you realize intercepting writes to port is only possible in virtual 86 mode on 386 and higher. That's completely useless for XT and 286 computers.
Click to expand...
Why? Why can't you replace the comm driver to be an mTCP shill?
 
whartung said:
Why? Why can't you replace the comm driver to be an mTCP shill
Click to expand...
Because basically zero DOS comm software uses the rudimentary BIOS/DOS drivers, they bang on the I/O ports themselves.

If there’s some particular piece of software you want to patch, sure, you could if you have either the source or the hacker-fu to do it the hard way.
 
Hi Mike. I've got one and don't know if it's MTCP or something else.
I've got a Socket 939 board here that uses the Nvidia MCP51 chipset. I used the Nvidia ODI driver from here. Ping works fine. When I do an ftp, I can log onto the remote server, but when I try to get a file listing or transfer a file, DOS (Win98SE DOS) dies with a hard hang. Any suggestions?
 
Intercepting the COM ports is not going to work for the reason Eudimorphodon presented; too much COM software polls the ports directly instead of using the BIOS, mostly because on old machines the BIOS was so horribly slow. On a machine with two serial ports it would work, but you'd be basically using a NULL modem cable on the two serial ports, letting your COM program do it's usual thing and then letting the TSR catch the bytes from the second UART and package them up. It's foolproof, but you are still limited to the physical speed of the COM ports and the interrupt processing overhead to service the serial port from the TSR.

Chuck - not enough details there, but I presume you are using ODIPKT along with the ODI driver to get to something that looks like the packet driver API. Try a very short file listing, and if that works I think the answer is buffering.

The last post in this thread at Vogons has the summary (https://www.vogons.org/viewtopic.php?p=940924#p940924) but basically the ODI driver is not allocating enough buffers by default, so packets are getting dropped. Short/small packets that are sporadic work fine if you are starved for buffers, but a directory listing or a file transfer is going to keep falling apart. As that linked post suggests, increase the number of packets at the ODI layer to 16 and try again.

Otherwise, I need to see packet traces to tell you what is going on. mTCP has a packet tracing facility that just requires you to set two environment variables.
 
I tried changing the buffers in net.cfg to 30,1514, but the behavior is the same. I have a dead-keyboard hang.
 

Attachments

  • IMGP0001.JPG
    IMGP0001.JPG
    1.8 MB · Views: 19
Hi Chuck,

Well, it's good to know the buffering is not the problem; inadequate buffers would just lead to slow connections, not freezes.

How long did you wait before you gave up and rebooted the machine?

Can you do the following?
  • set DEBUGGING=255
  • set LOGFILE=CHUCK.TXT
  • Run the FTP client until it hangs
  • Wait a few minutes, then give up and reboot.
  • Send me the file via email.
 
Oh, after a minute or so, I noticed that the keyboard was dead (no LED response to shift/num/scroll lock pretty much says that there's nothing servicing the keyboard).

I'll do the debugging steps for you.
 
Krille said:
Mike, I think Trixter's feature request in the last thread was a great idea. Did you look into that? It is a bit annoying that the file date/time stamps aren't preserved when transferring over FTP.
Click to expand...

I started implementing MFMT the last time, but it turns out that it was a draft extension to FTP that was not ever accepted. I can't remember the specific problems I had implementing it, but those problems and the fact that it wasn't even accepted as a formal extension led me to drop that work.
 
I just got my V20 IBM 5150 working with an Intel Ethernet board last night. Running with 640k on MS-DOS 5 with ANSI.SYS, Paradise VGA board, XT-IDE and 256 MB CF, and a CH375 ISA-USB.

DHCP gets the networking data correctly, and SNTP can set the clock as well.

I tried running TELNET, but I get a “Divide Overflow” error and the machine locks up hard. Have to kill the power to reset, since CTRL-ALT-DEL doesn’t cause a reboot.

Any suggestions before sending debug data?

mbbrutman said:
If you have found a possible bug in mTCP I'd like to hear about it now before the next release. Please post here for general wish list items, and for possible bugs please email me directly.

So far the next release will have:
  • TCP flow control fixes for even better compatibility and behavior on slow connections
  • A UDP fix. (Repeat after me .. Checksums are optional. Checksums are optional.)
  • Broadcast Ping
  • A more accurate SNTP client
  • HTTPServ: proper support for index.htm files and some minor bug fixes.
  • Proper HOSTS.TXT type support
  • DNS workaround that fixes DNS on "WiFi" modems using NAT/SLIP (*) read more below
There will probably be some other small fixes too.

(*) A side note on WiFi modems: a lot of people are using them as a way to do serial other the network. Over at TheOldNet.com Rich figured out that the ESP8266 can run a different firmware that has you use SLIP to talk to the ESP8266, then goes through a NAT layer to get on the network. In English that means these devices can put any computer capable of running a SLIP connection on the network via the serial port.

I've done it now with both a new Linux machine and a 386-40 running mTCP. While getting an old machine on the network as a terminal is neat, running TCP/IP natively is still better. 😀 That alternative firmware is not perfect but it is usable as-is right now and it has a lot of potential.

Mike
Click to expand...
 
TheDrip said:
I did not know that. There goes my dream.
Click to expand...
I vaguely remember trying out re-directing the DOS shell to the COMM port years ago, so your dream might not be totally dead.

If the source for CTTY is available, something might be sorta possible to code by those skilled in these dark arts.

retrocomputing.stackexchange.com

How do I connect a command prompt to a serial line in MS-DOS 6.22?

I am currently experimenting with DOS and am trying to run the command prompt on the serial terminal through QEMU. This is the command I have been using. command >COM1 2>COM1 <COM1 This s...
retrocomputing.stackexchange.com retrocomputing.stackexchange.com
 
BarryM said:
I tried running TELNET, but I get a “Divide Overflow” error and the machine locks up hard. Have to kill the power to reset, since CTRL-ALT-DEL doesn’t cause a reboot.

Any suggestions before sending debug data?
Click to expand...
I would verify that the TELNET executable has not been corrupted somehow. Also, I would test RAM with some diagnostic software like CheckIt.
 
Krille said:
I would verify that the TELNET executable has not been corrupted somehow. Also, I would test RAM with some diagnostic software like CheckIt.
Click to expand...
Good catch! I was initially running the code off an old MFM hard drive, which seems to have started to die and is throwing bad sectors. Turns out I had data corruption problems with it and the HTTP server code too, which came along for a ride when I later transferred the code to the flash drive.

Pulled it again from the sources and all is good.
 
You must log in or register to reply here.
Back
Top