• Please review our updated Terms and Rules here

TCP/IP Testing, Round 2

M

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,424
(Background - this is my TCP/IP code for DOS written using Turbo C++ 3.0)


I'm back at it again - I plan on doing better this time. (I've fixed the specific double delete bug that bit me last time, improved tracing quite a bit, and added a lot of consistency checking code.)

Just like last time, all you need to do is telnet to 24.159.203.149, port 2301. Once again, that's my Linux box, but today it is forwarding port 2301 to my PCjr. The commands are slightly enhanced from the last test, but it isn't anything highly interactive.

Up to 9 people can connect simultaneously. We didn't get more than 2 or 3 simultaneous connections last time, so I'm probably overly optimistic.

Some of you noted from last time that there is no character echoing or line editing. Telnet users on Unix machines will probably have local line editing, which makes things a wee bit nicer. The standard Windows telnet client doesn't do that by default, so you will type but not see your characters. That's a project for a different day.

Here is a picture of the machine you are connecting to, complete with the Western Digital 8003 Ethernet card grafted onto the side:

http://brutman.com/PCjr_WD_small.jpg


And lastly, if you remember, type in your OS and machine type as a command. It will complain about it being an invalid command, but I'll see it in the log and I'll have a better idea of what I'm testing against.

I'll edit this post when testing is over.


Thanks in advance,
Mike


Testing is still going!
 
Last edited:
Doing some "standard" tests right now. So far I didn't break anything, but there was a massive delay when I issued one of those prematurely ended sesssions:

$ telnet 24.159.203.149 2301 < /dev/null

All the available memory seems to stay consistent though. I left a bit of monologue into your log file. I hope you'll enjoy it.
 
I can't get at the log file now, but I will. :)

The massive delay I suspect is caused by the tracing that I am doing. The tracing is not noticable on the 386-40 with the big IDE hard disk, but the poor PCjr is using a SCSI drive through a parallel to SCSI adapter. When DOS 5 decides to figure out how much free space is on the drive, it can take 10 to 15 seconds.

I've noticed two problems:

- All sockets are reporting the same start time. It is a reporting bug, and I know where to fix it.

- There is no detection of inactive sessions, and no way to terminate them. That will be in the next round of upgrades.


I tried your redirect STDIN into telnet trick on my Fedora Core 2 system and was not able to do it. I think being able to pipe STDIN to telnet is 'broken'; that is what netcat is for. Unfortunately, netcat doesn't work because it sends a Unix 'newline' which is 0x0a, while telnet and everything else use a CR/LF pair.
 
it's looking pretty good, mike!

i connected and messed around with it from my quickbasic telnet client on a 386 DX/40 and had zero problems. still looking forward to your future telnet BBS program for DOS :)
 
Interesting .. how many times did you connect?

Your machine is showing up twice, one socket is in ESTABLISHED and one is in FIN_WAIT_2. It's like the DOS TCP/IP stack you used didn't finish disconnecting, or you rebooted the machine. Do you remember what you did?


-Mike
 
eh, yeah sorry it's my fault.

i didnt feel like loading arachne to download my previously written telnet client from rubbermallet.org so i just made another one from my TCP/IP base code in like 3 minutes but forgot to use the tcpInit function before calling tcpConnect lol... locked up the machine.

:stupid:
 
No big deal, and nothing to be sorry about. But I definitely need to add timeout support for orphaned sockets.


Mike
 
well at least it helped you find a problem. any time you need some more buggy code written, just let me know! haha :D
 
Mike: What does "not able to do it" mean, that the telnet client reported an error when you piped stdin into it? For that matter, I just tried to connect from a Solaris 2.5.1 (SPARCstation 10 w/ HyperSPARC CPUs) system using system default "telnet" and it (does not) work in the same way as I already noticed. I agree that it is not the intended use, but an interesting example of when a session goes wrong (which you now have fixed).
 
From the tcpdump, if I try to redirect something into telnet it opens and closes the connection immediately, without sending the contents of the redirected file or waiting for the other side to terminate correctly.

I need to research it more.

My code actually handled the packet timeouts and the reset relatively well. It was the double delete that killed it. :)
 
Testing is done ..

Things went pretty well, but I have a lot of logs to look through, and a lot of cleanup to do.

Thanks to those who telnetted in an exercised it!
 
Re the pic of your setup. What is the box with all the red buttons or lights under the PCjr monitor ? Looks very impressive.

I had to giggle at the pic, It could serve as a classic example of a hackers workbench with alll those cards hanging off the back. My work-benches are mainly full of dissasembled classics waiting for repair.

L
 
That "impressive" thing is JUST a fancy power strip. Has switches labeled monitor, computer, printer, etc. They were "all the rage" when I worked at Baxter Healthcare in mid 90s. They are nice to have if you still have large monitor to set on top of them.
 
As Chuck pointed out, it's just fancy power strip. For that machine it's not enough though - I've got a second power strip under the table to take care of some of the accessories.

In the picture you can identify:

- external SCSI hard disk
- external SCSI CD-ROM
- extra power supply used to feed the ISA bus card adapter
- Western Digital WD8003 Ethernet card, in the adapter and a spare on the table
- PC keyboard connected to the Jr through an adapter
- diskettes, spare sidecars, parts, etc.

Next to the Jr (but not in the picture) is the machine that I actually develop the code on. It's a 386-40 with 4MB RAM, 1.2GB IDE hard disk, and a VGA card. It runs IBM DOS 5 and Turbo C++ 3.0 fairly well. It sits in an original IBM PC AT chassis on the floor.

I need to get a picture of the entire mess and get it framed. I've done a lot of good work there. That poor PCjr has been the target of *every* experiment that I've done since I rediscovered the machine in 2000.
 
Still very impressive to a hardware-hacker-lite like me. My latest ventures were things like getting a PP Iomega-Zip to work on an Atari Portfolio and a Microsolution Backpack with internal soundcard on a Dauphin DTR1 486 sub-notepad and setting up a multiboot on an IBM P3. Setting up a PCjr to run SCSI, much less an Ethernet card using your own developed TCP program, is the work of temple-priests. And I have been around computers since a Digital Electronics course in 81, as well as working on IBM data-processing in the 50s.

I stand in AWE.
 
Micom - glad you like it, and I'm willing to share ...

Everything except the Ethernet card is readily available, and my work-around for that is to use a Xircom parallel port Ethernet adapter.

To run both a parallel port SCSI adapter and a parallel port Ethernet adapter requires two different parallel ports, which is not supported on a stock PCjr. My Jr has two parallel ports - the first step is to make them both bi-directional (PS/2 style) to improve the speed, and then to convert one to be the second parallel port. The modifications are on my PCjr web page, complete with pictures.

The TCP/IP software works with any ethernet device that has a DOS packet driver. The only useful utility I have now is 'netcat', which lets you send raw bytes to and from the machine. It's useful for sending files without firing up a full blown FTP client, and it can be used as a poor man's telnet as well. I'm not entirely done with the TCP/IP part, but when I am other apps will follow.

I've run the software on a PCjr, an XT, and a 386-40. I think I've got the fastest implementation of TCP/IP for the 8088 class machines right now. On 286s or 386s with more memory I could do better and add more features, but that's not top on my todo list.

On the Atari Portfolio - did you use the PalmZip driver? If not, you should look into it. PalmZip is a DOS device driver (DOS 2.1 and up) designed specifically for the Portfolio and the Zip. By happy accident, it works great on a PCjr too. (Well, maybe a little slow compared to what the machine is capable of, but functionally it is perfect.) PalmZip is much smaller than the Iomega drivers.
 
Yeah, from the programmer in Germany. A really nice guy. Can't remember his name offhand. He also very graciously sent me a PPZip driver for my Sharp PC3000 handheld which is really a Portfolio II made by the same guys who designed the Portfolio, the British outfit DIP.
When Tramiel did a thumbs-down on it Sharp snatched it up. Haven't done the mod yet tho, because it's a more serious hack. The pp's are non-standard, likely according to Tramiels specifications. Always figuring where he could make an extra few buck.

L.
 
You must log in or register to reply here.
Back
Top