• Please review our updated Terms and Rules here

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

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,269
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
 

TheDrip

Experienced Member
Joined
May 13, 2019
Messages
355
Location
San Diego CA
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.
 

dhau

Experienced Member
Joined
Feb 13, 2018
Messages
243
Location
Toronto, ON, Canada
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.
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.
 

Eudimorphodon

Veteran Member
Joined
May 9, 2011
Messages
5,102
Location
Upper Triassic
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.

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.)
 

whartung

Veteran Member
Joined
Apr 23, 2020
Messages
591
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.
Why? Why can't you replace the comm driver to be an mTCP shill?
 

Eudimorphodon

Veteran Member
Joined
May 9, 2011
Messages
5,102
Location
Upper Triassic
Why? Why can't you replace the comm driver to be an mTCP shill
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.
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
39,765
Location
Pacific Northwest, USA
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?
 

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,269
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.
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
39,765
Location
Pacific Northwest, USA
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

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,269
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.
 

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
39,765
Location
Pacific Northwest, USA
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.
 

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,269
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.

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.
 

BarryM

Member
Joined
Apr 29, 2022
Messages
14
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?

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
 

BarryM

Member
Joined
Apr 29, 2022
Messages
14
I did not know that. There goes my dream.
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.

 

Krille

Veteran Member
Joined
Aug 14, 2010
Messages
1,008
Location
Sweden
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?
I would verify that the TELNET executable has not been corrupted somehow. Also, I would test RAM with some diagnostic software like CheckIt.
 

BarryM

Member
Joined
Apr 29, 2022
Messages
14
I would verify that the TELNET executable has not been corrupted somehow. Also, I would test RAM with some diagnostic software like CheckIt.
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.
 
Top