• Please review our updated Terms and Rules here

IRCjr updates, Netcat, and DHCP Client

mbbrutman

Associate Cat Herder
Staff member
Joined
May 3, 2003
Messages
6,409
I've been spending too much time on this, but I really wanted to get another set of updates out. So it's 1:30am, and here is the latest set up updates. (And I'm swearing this off for a bit.)

  • IRCjr has better backscroll buffer handling, much faster screen writes and a new method of configuring the TCP/IP stuff. (That change is related to the new DHCP client discussed below.)
  • Netcat is my original application that I used to develop my TCP/IP code. It is useful so I cleaned it up and have made it available for download. If you have never used Netcat (nc) on Linux this is a gem .. kind of like a network version of a copy command.
  • Finally, I wrote a DHCP client to make setup easier. It also lets you plug directly into the back of a router or cable modem instead of having to fiddle with static addresses and parameters. I've tested against my Linux server, my cable modem, and DHCP servers at work - I'm interested in seeing how it does on other DHCP servers.

All of this is available at a dramatically expanded set of web pages at:



As always, send comments and bug requests to me and I appreciate any testing that you do. Hopefully you find some of this stuff useful.


Mike
 
just downloaded, will try it in dosbox or on the 286 as soon as i'm done with the lawn - i'm just taking a short break :p

i know it's not BASIC, but... you should gain an extra 2 lines by porting this to C: (at the bottom user input box)

Code:
LOCATE 25, 1
COLOR 15, 0
curpos% = LEN(userinput$)
IF curpos% > 79 then curpos%=79
PRINT RIGHT$(userinput$, 79) + SPACE$(80 - curpos%); 'the semi-colon makes PRINT not add a CR-LF
LOCATE 25, curpos%, 1 'makes sure the cursor is blinking

that would be much nicer to have more vertical log space but otherwise the screen shot looks great! :)

just limit the line's max length to like 480 or 500 or something, or if you really want to be picky just do the equivalent of this in your key input routines:

Code:
IF LEN(userinput$) < 510 - LEN("PRIVMSG " + channel$ + " :") THEN userinput$ = userinput$ + newkey$ ELSE BEEP

^ then it will make sure it's 100% compliant with the spec, of course. one thing i like that i put in leetIRC is that you just just press escape and it'll clear the whole line and you can start over instantly. 500 back space presses = bad.

btw, is there any way i can get the course? you're doing it with Turbo C v3, right?
 
Last edited:
seems to interface with the latest build of my DOSIRCd perfectly!

ircjr.png
 
Your suggestion to the user interface is noted but I am not inclined to change it any time soon. The screen refreshes caused by your scrolling trick would make the user interface quite a bit slower.

I spent a great many hours writing tight C and assembly code to minimize wasted cycles in the TCP/IP stack. I'm going going to burn those cycles on a UI feature that doesn't have a great return for the investment. To me, making it responsive for both the screen and the socket connection is the highest priority.

<snip>off topic comment goes here</snip>


Mike
 
Last edited:
For those of you watching this thread .. you may have noticed some deletions. I normally leave discussions alone so that people can judge things for themselves, but I really want to use this thread for feedback and suggestions. So try to keep the posts/replies on topic and maybe we'll get three pages of good conversation.

I've already moved the programming discussion to another thread.
 
Newest version posted ..

Changes:

  • SLIP over a packet driver (SLIPPR) - Thrashbarg, this is for you ...
  • IRC nickname changes recognized now
  • IRC nicknames up to 20 chars (although the spec still says 9 chars)


The SLIP support lets you use everything over a serial port - no need for an Ethernet card now. To use it find a packet driver called SLIPPER, use the 'ether' option to simulate Ethernet on the packet driver, and set an extra environment variable.
 
I don't want to act as a nasty competitor but the "keyword" netcat reminded me,
that i too recently wrote a clone of this famous program.
It is based on the WATTCP stack,
is intended to be used under true plain-vanilla DOS and even contains a DHCP client.

Should someone be intereseted in trying it, please let me know.
 
That's ok .. welcome to the Vintage Computer forums!

I wrote my netcat to test the TCP/IP part of my TCP/IP stack. Besides making sure that it is fast, I wanted to make sure that it was sending the bits correctly too.

I've had some conversations with Erik Engelke (the author of WATTCP) about how he implemented it. It is funny how much I rediscovered on my own years after he did it in WATTCP.

All of my applications run under DOS 2.x or better on real 8088 class machines. The screen shots are generated using DOSBOX because it is so much easier than taking a digital picture of a real curved computer monitor. :)
 
I never got so far to write my own TCP/IP stack :)

Initially i only wanted to compile a boot disquette with MS-DOS, some packet drivers and a couple of more or less usefull programs which make use of the packet drivers. When looking for such programs, i came across a port of netcat which looked quite interesting, but when i actually tryed the program, it did not quite behave the way i expected it to do (politely said :))

As it came with sources i first wanted to "debug it a litte bit" but very soon ended up with re-writing it more or less completely. I have just made some more modifications, some bugfixing and improved telnet support, so it now takes another round of intensive testing. Unfortunately, the more features a program has got, the more complicated is the testing.
 
Unfortunately, the more features a program has got, the more complicated is the testing.

So true.

I've been going back over my code trying to understand everything and cleaning up potential problems. The more subtle a bug that I fix, the more difficult the testing becomes. For example, it is easy to force a packet to be dropped to test the retransmit code - just unplug the cable for a few seconds. It is much hard to initiate a connection and then get a dropped packet before the SYN/ACK packet. Why does one want to do that? To test the code that cleans up new incoming connections that didn't fully get established ...

I'm also finding that has I 'bulletproof' the code it is getting bigger. I've always had to make choices between size, function and speed, and I'm finding that function is winning. I'd much rather have 'automatic' code that protects the application program from memory leaks and poor programming rather than try to debug something I don't fully understand.

I figure I'll be done in a few more years. :)

You should post your versions of the code. I'm interested in how other people tackle the DOS networking problem.
 
You should post your versions of the code. I'm interested in how other people tackle the DOS networking problem.

Well, it turned out to be a bit more complicated than i expected.
I wanted to improve telnet client support and had to learn the hard way,
that it takes a bit more than just the processing of some ansi escape sequences.
But as it looks now, i eventually succeeded.

Next step will be to find out how to post such a file in this forum. :confused:
 
And another round of updates posted:
  • TCP/IP Zero Window support (including probe segments)
  • Check for presence of packet driver before trying to run
  • Cleanup initialization process
  • DNS resolver support in netcat
  • Some small bug fixes in 'listen' and 'accept' calls

Get the latest at ... http://www.brutman.com/Dos_Networking/mTCP.html
 
December 30th Updates

December 30th Updates

And another round of updates posted!

  • New command line DNS name resolver
  • Timestamps and logging in IRCjr
  • Small bug fix in Netcat
  • Performance improvements

The big change here is the performance improvements - with the changes to the TCP code in mid December and some small tweaks to the applications, this is the fastest version of the code ever posted!

The command line DNS name resolver is pretty neat too. Turn on the verbose mode and see the interaction between your machine and the nameserver.


Get the latest at ... http://www.brutman.com/Dos_Networking/mTCP.html
 
And yet another round of changes, mostly for FTP:

  • Mget and Mput commands
  • Prompt command for controlling prompting with mget and mput
  • Rename (on server)
  • LCD (local change directory)
  • Environment variables for controlling buffer sizes

Once you use FTP for transferring files, you'll never go back to shuffling floppies around ...

Get the latest at ... http://www.brutman.com/Dos_Networking/mTCP.html
 
Wanted: Your wish list!

Wanted: Your wish list!

I've been working on code again, adding some new function and cleaning other things up. In particular:

  • IRCjr: Move the environment variables for Nickname, Username, and Realname to the config file from environment variables
  • IRCjr: Add user defined connection timeouts - this makes it easier to connect to slow/unresponsive servers
  • IRCjr: Allow for users to abort the connect and registration when the other side is being really slow
  • Configuration file: add the ability to use blank lines and comments. (The config file will be used more and more as I make settings user selectable.)
  • FTP: Slim down the memory usage a few bytes
  • Base TCP/IP code: allow for user defined socket connect timeouts

I am messing around cleaning up the user interfaces and making the programs more parameter driven. While I am doing this, I'd like to hear from you what else I should be fixing. Any of the four programs are fair game:

  • Dhcp client used for configuring your TCP/IP parms
  • IRCjr - IRC client
  • FTP - FTP client
  • NC - Netcat

Think of your favorite versions of these programs and let me know what I can add to make my versions better/competitive ..


Thanks,
Mike
 
I have a request for the FTP. Remember when you said:
mbbrutman: Were you just trying to automate the login sequence and then use it interactively? If so, I'll provide another way to do that, probably by a configuration file or environment variables.
Yes please. :)

To everyone else:
(rant) There seems to be great interest in DOS and vintage networking so how come nobody's chiming in here? There are very few programs out there (good or bad) that will go on the net. This stuff is good and it's something we need. So wake up! /rant
 
Ole,

In my latest code drop (yesterday) I reworked the configuration file so that applications can store what they need in it too, not just the TCP/IP settings. So while this function doesn't exist yet, I can now add it more easily. Look for it shortly.


Mike
 
New code has been posted!


Some of the changes/new features:
  • New Ping command!
  • Support for ICMP - your machine will respond to PING now
  • Bug fix in FTP: you can change directories now using the lcd command
  • Bug fix in FTP: handle more variations of the PASV response string (used with EZNOS)
  • DHCP Client: Handle Ctrl-C and Ctrl-Break correctly
  • All: Small performance improvements
  • DHCP, DNSTEST: Smaller code size and less memory required


Regards,
Mike
 
Small warning - I have had reports that the ping timing is off .. it depends on the machine. For example, on my V20 equipped PCjr it is off by 15%.

I can fix the problem, but it disables the keyboard on machines like the PCjr and the IBM Convertible (5140). I have to reprogram the 8253 timer to get higher resolution timing, but the side effect is that for those machines I have to disable NMI. On the other hand, the timings are rock solid now.

In 5 years of working on my TCP project, I've never had to put machine specific code in .. grr.
 
Back
Top