• Please review our updated Terms and Rules here

Bring out your dead! (Looking for mTCP bugs)

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,407
It's that time again! I'm getting ready to roll up a few bug fixes into a new release so please send me your bug reports and wish list items. (I'll also be going through the older wish list items too.)

The next release will have the following:

  • Telnet: RLE graphics support
  • Telnet: A work-around for an invalid ESC sequence being sent by Linux systems when setting the scroll region.
  • DHCP: Formalizing the work-around for bad routers that don't respond with the assigned hostname.
  • HTGet: set the file timestamp when saving the output to a file
  • HTTPServ: provide a version that uses BIOS screen writes for use with DESQView
  • TCP library: Bug fix for machines using Explicit Congestion Notification
And the big change is Unicode support in IRCjr and Telnet, for both sending and receiving. No more "mojibake" on the screen when somebody sends you UTF-8. And if you have a European layout keyboard or need proper accented letters then you'll want this update.
 
And it's finally available: http://www.brutman.com/mTCP/mTCP.html

Besides the list above there were some more bug fixes, some of them surprisingly old. HTTPServ also now has an SNTP client built in so that it can have accurate time across days or weeks. See the release notes for details.

-Mike


PS: At the moment everything except for large PDF files is being redirected and being served from a PCjr. I've got the PCjr and networking gear on a UPS and I want to see how long it can stay running. (My bet is that I'll have to shut it down in five weeks to clear the log file.) Here is a picture of the actual machine:


Brutmanlabs_testing.jpg
 
Yep. I'm happy to have the latest bug fixes and work arounds officially out there. Testing has taken a few weeks longer than I planned for because I was trying to find some very old bugs, and they were difficult to recreate and track down. We should be good for a few years now.
 
Thank you for your continued work on this!

I'll see if the latest tweaks fix some issues I had trying to run "screen" sessions via the telnet client as soon as can find the bandwidth.
 
Screen generally runs fine.

In this version there is a fix for the DECSTBM terminal code, which sets the top and bottom margins of the screen. Everything I can find about it says the row and column numbering starts at 1. And Linux (apt in particular) was sending 0 for the starting row, generating a mess.

The hilarious thing is that I had a years old "Fixme" comment in the code because I wasn't defending against bad input. Lesson learned.
 
Perhaps not a bug, but I've installed an ECS NForce-3A Socket 754 motherboard in one of my systems. I'd like for it to have DOS networking. The NIC uses the Realtek RTL8201BL chip, which means a layered driver to get packet service. (LSL.EXE and ODIPKT.EXE). The problem is that the setup connects, but hangs the system solid if I try to do any ftp transfers. (I mean it takes a power-recycle or hardware reset to get out of the hang--keyboard is dead).

Okay, I can deal with that--maybe. I've got extra PCI NICs and can use them:

1. A no-name card using the Davicom DM9102AF chip
2. A Netgear FA310-TX using the NGMC169B chip
3. A Cogent EM110TX using the Digital 21140-AC chip (this card even has a BNC in addition to the RJ45)
4. A Diamond Flower DFE 530TX+ card using the DL10038D chip
5. An HP 5064-6764 card using the MPX EN5038 chip

Which of these is likely to work with MTCP and what drivers should I use for them? Surely out of the 6 NICs (including the Realtek) should have one working candidate. FWIW, Linux Bullseye works with all of these--and WIndows XP for most of them.

Thanks in advance!
 
Alas the only thing not ISA (and 8-bit at that) that I've run mTCP on is the integrated VIA ethernet on an ancient C3 EPIA Mini-ITX board. Which worked fine, other than the packet driver being relatively huge compared to the one for the RTL8019 in my Tandy 1000. (Like 30K resident instead of ~9k.)
 
I don't have recommendations on PCI cards - there are too many out there. I use a Davicom ISA card on my ISA test bed and it's been a great card; I also believe those are NE2000 compatible as the worst case. The Netgear should have a reasonable packet driver. The others, well, it depends on the quality of the packet diver. (Do those even all have packet drivers?)

People use other things and add the compatibility layer if a packet driver is not available. That's fine if you have no other choice, but debugging that is painful as you have found out. When it doubt go with the card that has a packet driver that doesn't look like an afterthought.
 
I’m pretty sure the DEC Tulip-based card has a packet driver, come to think of it. That chipset is both ancient and once dirt-common.
 
I'll give it a try when I get the chance. I found packet drivers for the Diamond Flower one, but when run, they can't find the card--but Linux finds it just fine.
 
Can you do me a favor and locate the driver? The card itself dates from 1995 or so. Cogent was apparently absorbed by Adaptec at some stage.

It might be worth trying the Crynwr driver. The Tulip driver is dc21x4pk_11_4.zip. That is the annoying thing about PCI cards, is drivers often key to a PCI ID, so you might have two exactly identical cards (based on the same reference design from the chipset maker) from two different manufacturers but their drivers won't work on each other because they're hardcoded to only work on the matching card ID.
 
UPDATE: I'm delighted to report that the Netgear packet driver did the trick--thank you @Krille!

This is what I suspect: If you've got a ODI driver for a PCI card and attempt to wedge in packet support using lsl and odipkt, it won't work. It will appear to work--that is, you can ping and even log into an ftp server, but after that everything goes to hell. I suspect a stack or buffer issue, but I can't prove it. This is the third system with either integrated NIC on the motherboard or one using a PCI NIC with only ODI support that I've observed this behavior.

For whatever it's worth...
 
Back
Top