K1TTT CT Ethernet TSR

NOTE! New info on networking CTwin and CT/Nettsr at end of this page.
K1TTT CT Ethernet TSR
Version 0.4-Beta 13-September-1997
Usernote update 8/22/99
This software is a plug in replacement for the CT COMTSR's that provides
CT with a connection to an Ethernet card for CT network connections.
It does not provide TCP/IP Telnet access or anything else, only CT
to CT network services that replace serial port connections.  (Check
out my Telnetx program for Telnet connections to Internet PacketClusters)
And of course I reserve all rights to this software, but will not be
held liable for any damage caused by it... now isn't that a loaded
phrase!  And one of these day's i'll stop calling it a Beta version,
but that won't change the disclaimer.
Instead of serial cables use coax.  Instead of tying up 2 com ports
to daisy chain the network, or getting an 8 port board as a hub,
or setting up the special one wire ring to use a single com port, you
get to use all your com ports for other things.  Also the network
doesn't break if a machine in the middle of the chain goes down.  And
the setup is much easier, no more db9-db25 adapters, null modems,
trying to figure out com3 or com4 settings, hunting for extra i/o
cards, etc.  Just coax with bnc's and a single card to setup that
usually goes on a different irq than com ports anyway.  And the cards
can be bought for about what more com ports cost anyway.  Plus you can
use the cards for other network tasks when you aren't running CT.
CT uses a simple broadcast protocol for its networking.  There is no
handshake or ack messages from a receiver to the sender.  The checksum
ct uses is only used to reject bad data, not to ask for retries.  This
fits nicely into the TCP/IP UDP (User Datagram Packet) protocol using 
packets addressed to a network broadcast address.  Packets using this 
protocol are essentially thrown out onto the wire for anyone to receive 
and process if they want it.
More Technical How...
In this tsr I am taking the data that CT would put on the serial line and
wrapping it in a UDP frame.  The 'from' address is the ip address that is
supplied on startup, the 'to' address is computed from the ip address and
a network mask word.  The default is which is the
network wide broadcast address.  the 'to' and 'from' port numbers are both
set to 9870 which can be changed at startup.  I do fill in the UDP checksum
fields, but they are not used on receipt.  All packets received are passed
to CT since it does its own checksum checks.
Note:  This is NOT like the COM2NET (or is it COM2TCP?) com port redirect
utility.  CT does not know what type of device it is reading or writing,
it only knows to call a specific software interrupt with certain registers
and memory locations setup to send or receive.  This means that I could
completely divorce from the com ports leaving them totally free for other
The shortcoming of this is that its a connectionless protocol.  Much like
the CT protocol itself there is no ack or retry capability.  To provide
that type of capbility would take a much more complex protocol, like real
TCP socket connections.  This would also make for a more complex setup since
each machine would have to establish one or more connections to other
machine(s) on the network.  Packets would then have to be routed from one
machine to the next which would leave you open to the loss of one machine
breaking the network, or having to specify one machine as a server that
would route everything to and from each client.  In any scenario this becomes
much more complicated and also takes a much larger tsr.  So far I have kept
this tsr only about 50% larger than the comtsr's and I should be able to
shrink that as I clean up more of the unneeded TCP and UDP code.
My thanks to K1EA for providing enough of the source code for the COMTSR
for me to confirm what my disassembly was showing me.  Even though I only
ended up using one header file and snippets out of a source file (that
didn't even match the disassembled COMTSR or the header file) it was useful
to see some of it.  Now if I could just get the TSR builder package that
he uses I could pretty this thing up some more.
The UDP protocol code (very little of which hasn't been modified in some
way now) is from the 'WATTCP - TCP/IP library routines' Copyright
(c) 1990, 1991, 1992, 1993 Erick Engelke.  This package is available on the
www and contains some other utilities and demo programs for dos based tcp/ip
If you try it i would like to know what your hardware and software
is:  i.e.
DOS version:
CT Version:
Nettsr version:
Ethernet card type:
Other stuff (dvp, digiboard, other com cards):
And answers to questions:
Did you have to do anything special to get it started?
Did you see ct's bad checksum message?  if so, how often and
could you relate it to any particular event?
Other comments or suggestions?
Please e-mail response to k1ttt@arrl.net
Required hardware:
        Ethernet card, cables, terminators, t's, etc.  (remember, when
        using the coax network it must be terminated at both ends with
        a 50 ohm load.  no, buy it, don't use your dummy load!)
Required software:
1.      Packet driver for Ethernet card that conforms to FTP Software, Inc
        packet driver specification.  These are normally included with
        the software drivers for the cards in a directory called 'Packet'.
        If your card doesn't come with one there are public domain sources
        for many of the cards.
2.      CT 9.??  (i have only tested with 9.27 through 9.40)
Basic steps to use with mostly default parameters:
1. install your network cards and test them according to manufacture's
        instructions.  be sure to avoid irq and port address conflicts.
2. copy nettsr.exe and the packet driver to the directory where you have
        the comtsr*.exe's or somewhere else in your path if you want.
3. load the packet driver (set it's software interrupt to 0x6f, see 
        it's help or readme file for how to do this)
4. load nettsr before starting ct in place of the comtsr you would use 
        for your network.  the only required parameter for it now is the 
        ip address which must be different for each machine on the 
        network.  i.e  'nettsr', see start.bat example.
4. setup ct to use com4 as network (baud rate doesn't matter)
Command line parameters:
usage:  nettsr my_ip_addr [[[[ sw_int ] broadcast_mask ] broadcast_port ] send_to_ip]
i.e. nettsr 100 9870
note, using send_to_ip over rides broadcast_mask
one important note...  this is a rude and crude command line interface.
the parameters all have to be in order.  So if you want to change just
the port number you would have to put in all the others before it.
Now, what are all those new parameters:
my_ip_addr = the ip address of your network interface card.  This is
the only required parameter.  It is needed to identify the outgoing
packets and in case you have multiple interface cards it identifies
which card to use for the network.
sw_int = this identifies which comtsr* the tsr is supposed to imitate.
These values are in decimal as follows:
        comtsr4 = 100  (default)
        comtsr3 = 99
        comtsr2 = 98
        comtsr1 = 97
broadcast_mask = this is used along with my_ip_addr to create the
address that the tsr sends to.  basically the program takes the ip
mask you put in here, inverts it, and or's it with my_ip_addr to 
make the broadcast address.  
        my_ip_addr      broadcast_mask  send_to_ip  (default)
This should only be useful if you are on a lan with the right 
router setup to handle subnet broadcasts.  Before using this tsr
on a network where you might have to use this parameter check with
the network administrator for proper ip assignments and what the
net mask should be.
broadcast_port = this is the ip port number that the tsr uses to
listen on and broadcast to.  It is in decimal.  The default value
is 9870.  This should only have to be changed if that port is already
being used on the network for something else.
send_to_ip = lets you specify the address to send to.  Using this
overrides the calculation done with the broadcast mask by directly
setting the address the tsr sends to.  This might be useful for 
making point to point connections over the internet, but i don't 
have any way to test it at this time.  Let me know if you find a 
use for this one.
These are the error codes that may show up on nettsr installation:
1    BAD_HANDLE         Invalid handle number,
2    NO_CLASS                 No interfaces of specified class found,
3    NO_TYPE                  No interfaces of specified type found,
4    NO_NUMBER                No interfaces of specified number found,
5    BAD_TYPE                 Bad packet type specified,
6    NO_MULTICAST             This interface does not support multicast,
7    CANT_TERMINATE     This packet driver cannot terminate,
8    BAD_MODE                 An invalid receiver mode was specified,
9    NO_SPACE                 Operation failed because of insufficient space,
A    TYPE_INUSE         The type had previously been accessed, and not released,
B    BAD_COMMAND              The command was out of range, or not implemented,
C    CANT_SEND                The packet couldn't be sent (usually hardware error),
D    CANT_SET                 Hardware address couldn't be changed (more than 1 handle open),
E    BAD_ADDRESS              Hardware address has bad length or format,
F    CANT_RESET         Couldn't reset interface (more than 1 handle open).
Basically there isn't much you can do for any of these besides reboot
and try again.  They probably mostly mean you have loaded a second copy
of either a packet driver or nettsr when it is already running.
1. If you have to change a parameter on either the packet driver or
nettsr you MUST REBOOT first since there is no way to remove either of
them from memory once they are installed.  trying to load a second copy
of nettsr will produce error code 0xa==TYPE_INUSE which means the old
copy is still trying to receive that type of packet so the packet
driver won't give it to anyone else.
2. The software interrupts you specify for the packet driver and nettsr
MUST BE DIFFERENT.  AND the packet driver one must not conflict with
any of them used by CT.  This, and other limitations, mean that the 
interrupt for the packet driver should probably be between 0x69 (105
decimal) and 0x6f (111 decimal).  I recommend 0x6f.
Troubleshooting and detailed notes:
My config/autoexec/start.bat files:
config.sys file, nothing specific here, watch out for
the parameters on the devicehigh command as they may be
unique to particular machines.
autoexec.bat file, not much interesting here either,
again watch out on the lh command parameters.
rem WARNING! the LH parameters may be different for your machine
LH /L:0;1,42384 /S C:\DOS\SMARTDRV.EXE 128
PATH C:\DOS;c:\;c:\ct9;c:\util
rem if you hit ctrl-break here you can get out of startup
rem without loading packet or nettsr drivers that could mess
rem up other stuff.
rem startup the log for the contest
netct9 cqww -now
netct9.bat file.  this does all the work.  note that it
can be passed 3 parameters that are then sent to ct when
it is started.  this way you can start different logs and
add the -now command in the autoexec if you want.
rem load packet driver, assign sw interrupt 0x6f
pkt9008 0x6f
rem load nettsr, use bare minimum options if possible
rem each machine must have unique ip address
rem default is to replace comtsr4
rem now do rest of ct startup
rem load at least one comtsr even if you don't need it
rem it just seems to make ct happier
CD \ct9\logs
rem command line parameter 1 is log file name
rem command line parameters 2 and 3 can be anything else
ct %1 -d %2 %3 -fo  -ky1h
Sort of a proceedure to sort out tsr problems:
to sort out tsr's...
1. take notes.  make a table of devices, irq's, hardware addresses,
software interrupts and keep it with the computer for later reference.
2. check hardware irq assignments.  check jumpers on dvp, use msd, or
norton sysinfo, your system bios(on newer machines) to see what irq's
are used and to be sure there are no conflicts.  irq conflicts are
commonly recognized by one-way links.  usually the computer can send to
a com port or network card but will not receive, or will lock up on the
first receipt of data.... so it can be delayed failure or strange
behavior.  note that in pci bus machines you may have to manually set
the bios to exclude irq's used by old isa cards from automatic
assignment by the bios.  note also that on most modern nic's there is
a configuration program that comes with them to set irq's and addresses
and run tests on the card.  run this utility and make sure all the 
card tests pass.  many of these utilities also include a loopback 
test between 2 machines, if it has one of those try it also as that
will check your wiring and the other machine.
3. check hardware memory address assignments.  these are the usually 3
digit hex addresses like 0x2fb, 0x300, or like 304h, etc that often are
talked about along with setting irq's in setup instructions.  note, most
devices use more than one address.  many use 4 addresses, like 0x300
through 0x303, or 8 addresses.  but some (like one nic i have heard of
recently) uses 32 addresses... so it would use 0x300 through 0x320. 
These addresses can not be shared or strange things may happen like
devices do odd things.  these are set by jumpers or by running network
card setup programs to set them in eeprom on the card.  
4. check software interrupts.  software interrupts are a method of
communication used between (usually dos) programs.  most often used
between tsr's that are resident in memory and other programs (including
other tsr's).  these are similar to irq's in that they can not normally
be shared.  they are often described by a 2 digit hex number in a format
like 0x60 or 60h.
now it gets messy.  there are some ranges of addresses that are
'reserved' or commonly used by certain pieces of software for
communications by default.  these are often not advertised or not
obvious in the software documentation.  the following are common
defaults and ranges of interest for ct and nettsr use:
0x60 dvptsr default, some packet drivers default
0x61 comtsr1 default
0x62 comtsr2 default
0x63 comtsr3 default
0x64 comtsr4 default, nettsr default
0x60-0x6f is the normal range used by packet drivers, they often default
to 0x60 if you don't specify anything else which will kill the dvp. 
nettsr will only search this range to find the packet driver, if you
assign the packet driver one outside this range the nettsr will fail to
note, these are usually entered as hex numbers.. but nettsr takes this
argument in decimal so remember  0x64 = 100 decimal if you want to
change it.  (just to add to the confusion nettsr reports the interrupt
number in hex when it loads)
The most frequent problem seems to be that the packet driver takes 0x60
which kills the dvp or vice versa.  also note that you can not load the
comtsr that you set nettsr for.. so you can not use comtsr4 if you load
nettsr with the default interrupt.
conflicts in sw interrupts are hard to find.  norton sysinfo may report
which interrupts are used if you run it after each tsr is loaded.  there
may also be other programs that report which ones are being used (i
don't remember if msd has those or not).  but note that they will not
find conflicts, they will normally only report the last program that was
loaded that wanted to use that interrupt.  symptoms are usually bad,
either programs won't work or will crash outright.  these are usually
fairly crude communications between programs and don't have much room
for error checking or reporting so results are often simple crashes.
5. Check IP address assignments.  Each machine must have a uniqe ip
address.  IP addresses are normally written in a format like which is 4 decimal numbers between 0 and 255 separated by
periods.  Don't confuse this with the number the nic setup program uses
or that the packet driver load may report that looks like:
00:44:5e:10:44:00  this is your unique world wide hardware address for
that card, it is used by very low level network protocols and is not
related to the IP address in any way.  (note that this unique id code
was around long before intel decided to put one in the pentium 3 chip).
IP addresses have some odd rules.  in most cases it is best to stay away
from using 255 for any of the 4 values.  it is also best to avoid 0 for
either the first or last numbers.  using a value of 10 for the first
number uses a block of addresses reserved for experimental use which is
why i use them.  i prefer to set addresses like,,, etc for my 10m, 15m, and 20m stations respectively so when i
run a sniffer program or use ping to test the network i can tell which
machine is sending what packets.  WARNING!  if you share a wire or
router with another network you should contact the network administrator
to be sure that you don't do something that will confuse the rest of the
network.  they are the best ones to talk to about manually setting
broadcast addresses and masks if you must do that.  assigning bad ip
addresses will normally be seen as one-way or no data transfer, it can
also cause windows 95/98/nt machines to barf when connected to the
network.  NOTE that once the nettsr is loaded you can use a windoze
machine on the network to 'ping' the nettsr to see that the wire
connection is proper and that the software is running.  to do this open
a dos window and use a command like 'ping' to check the
connection and round trip time.
another part of the IP address that is often ignored is the 'port'. 
different ports are used by different pieces of software by default. 
i.e. telnet normally uses port 23, http normally uses 80 and/or 8080.
nettsr defaults to 9870 which is normally not used, but again if you are
sharing the network with other services check with the network
administrator to be sure that port won't cause something else on the
network to barf.  there are some of the fancy new network security
programs that will report unusual activity on certain ports and
6. other things:  
a. loadhi or lh, these may or may not work with packet drivers or other
tsr's like nettsr or comtsr's.
b. memmaker often tries to loadhi or change the order of loading
c. nettsr can not be removed from memory, and neither can most packet
drivers.  therefore before each change you attempt in parameters you must
d. for some reason nettsr may not work unless at least one comtsr is
also loaded.  i have not figured this out yet, but if everything seems
to load but doesn't work try loading a comtsr even if you don't need it.
e. i recommend using a minimal config.sys and autoexec.bat file for
starting ct with all the tsr's. 
f. normally an nic can not be shared between a packet driver and other
network protocols.  so you should not expect to be able to run other
networking programs at the same time as the packet driver/nettsr.
g. there is a driver for win-95 that simulates a packet driver to let
you run nettsr in a dos window.  it does work, but in my testing was not
exceptionally stable... which was probably more of a win-95 problem that
with the driver.
Laptop notes from I4UFH/IR4T
I have installed the PCMCIA card with the SYSTEMSOFT CardSoftTM PCMCIATM
Software Suiteit's a complete DOS package that allow to install a wide
variety of PCMCIA card into a wide type of LapTop. The last version is 
the 3.1 and it's dated 1994, I think it's is not more supported, may be it's 
available into shareware agreement.
Another program called Cardwizard 5.0 it's currently available on Internet,
with same features.
Follow is the config.sys file with some explanation :
>> himem.sys needed to load emm386.exe
device=emm386.exe noems /X=D000-D8FF
>> emm386.exe needed to exclude the PCMCIA ROM address (normally between
D000 & D8FF
>> ss365sl.exe it's the socket service, and it's device dependent, this
>> one it's the most common because it's drive the INTEL 365 PCMCIA adapter 
>> the most used between the Laptop manufacturer. More drives are available, 
>> for another hardware i.e. IBM or Cyrrus chips.
>> cs.exe it's the card service, it the driver  interface between the
>> Socket Service and the Packet Driver, it's need a config file supplied  
>> from the Card Manufacturer.
device=csalloc.exe csalloc.ini
>> CSALLOC is a DOS utility that scans the system  for available memory,
>> I/O port, and IRQ resources, updates the file CSALLOC.INI  with this 
>> information, then displays the  list of available resources that can 
>> be used by Card Services.
device=cardid.exe cardid.ini
>> This client device driver detects the insertion and removal of PC
>> cards, automatically determines the card type  upon insertion, and 
>> then configures the card and slot/adapter.
device=dfe650pd.sys 111 /100h
>> Packet Driver of the PCMCIA card, supplied with the PCMCIA Card. The
>> "111" is the Packet Driver IRQ (0x6f) and the "/100h" set the card at 
>> 100 Mb (optional)
Autoexec.bat it simple only with the nettsr :
nettsr 100 9870
Note: only 'nettsr' is really needed as the others are just 
repeating the default values.
More PCMCIA and laptop notes collected by Tom K1KI
packet drivers are dos only drivers that are unique to the hardware on the
card.  you have to figure out what chipset is on your card and then find the
drivers to go with that.  did any disk come with the cards?  the packet drivers
are usually very small files that are in a directory on the floppy called
'packet' or something like 'pkt' or 'pktdrv'.  if you can figure out what make
the cards really are you can check out the driver collection at
ftp://ftp.crynwr.com/drivers/ or from
http://www-commeng.cso.uiuc.edu/nas/nash/packet/packet.html . note, packet
drivers will not work under windows.  if you have the windows drivers for the
cards there is a source for an ndis-packet driver for windows that simulates the
packet driver and lets you use nettsr in a dos window.  it is available from
http://www.danlan.com/ . there is an old version for win95 that is free, the new
one called version 2.5 works on win98/nt but is not free, though it is cheap.
> Anthony Brooks wrote:
> I downloaded your nettsr program and I keep getting a message "no packet
> driver found"  I read your information and did some searches on the net to no
> avail.  Could you recommend a packet driver to download.  The cards I use were
> purchased on the secondary market.  Windows 98 is the op system.
> Any help would be appreciated.  Thanks.
> Anthony, KU4RG
I just found a great document providing a lot of information
on configuring packet drivers and also using non-packet drivers
(ODI, NDIS) ...
check it out at:
Filip, ON1AFN
> On Thu, 12 Apr 2001 03:10:15 +0100, Roger Huntley wrote:
> do not fully understand how you link 4-5 laptops together while running
> CT.  The manual discusses connecting two but if each laptop only has one
> serial port how do you connect multiple laptops together?
You have two options:
1, Use serial cables and the LOOP configuration. You can find the
description on the CT homepage.
2, Use PCMCIA Ethernet cards and K1TTT's network driver. It's very neat and
works robust. However you may find it difficult to get DOS drivers for the
latest devices.  I used both the Xircom 10/100 cards and the 3COM 10 Mb
card. They were OK.
DL6RAI has a very nice writeup of the NETTSR driver and it's setup with
different network adatpers. You can find it at www.Bavarian-Contest-Club.de
73 de Zoli HA1AG
At 07:00 PM 11/30/2001 -0500, I wrote:
>Looking for suggestions on PCMCIA (PC card) ethernet cards to use in my laptop to connect to my CT ethernet network.   The doc on K1TTT's website has a little info about using them from I4UFH but not any specific suggestions about brands with DOS drivers that people have successfully used.
>Sent direct to me and I'll summarize for the group.
Thanks for the helpful information!  Here are the responses:
 From William Liporace NA2NA    na2na@vqsl.net
To use a PCMCIA card with a laptop, you need the DOS card drivers for the 
laptop and the PCMCIA card. This will allow CT to use the NIC via DOS. 
You can go to any web site and check out what you need.
I believe I have around card here. I do not know if I have DOS Drivers 
handy. I may even have a 3com. The laptop manufacture's WEB site may have 
the info you need.  If you need any help let me know. I will have a few questions :-)
 From Zoli Pitman HA1AG  ha1ag@compuserve.com
See www.qsl.net/ha1ag -> SO2R description. You will find what I use there 
with links to the products themselves.
>From  Rick Dougherty   NQ4I@compuserve.com
I use a LinkSys ethernet card (Abt $39) in my Toshiba Satellite 115CS (Older laptop) 
Pentium 100 mhz and it works great with DOS drivers(Packet)
 From Hank Kohl K8DD     k8dd@arrl.net
I guess the first requirement is price! 
And the second one (and most important) is the availability of packet drivers.
I use an EXP ThinLAN 10 MHz card and a Xircom 10/100 MHz.
The EXP came with packet drivers. Had to go to Xircom tech support for the drivers for Xircom.
Those are the only two I've used here with good luck.
 From Dan Karg  WR0DK  dkarg@mn.mediaone.net
This is not strictly related to PCMCIA cards, but I have successfully used an 
older LinkSys "Pocket Ethernet Adapter plus' Ethernet adaptor that plugs into 
the parallel port of my laptop. It has both coax (thinnet) and RJ-45 (10BaseT) connectors. 
It is not quite as slick of a solution as a PCMCIA card, but it will work on 
any computer and you don't get wound up in PCMCIA card drivers and all of 
that under DOS. 
I'm not sure these are still available, I picked mine up a few years ago on 
of the retailers clearance tables.
 From Dennis NB1B    NB1B@mediaone.net
At VB2V we used 4 different models of laptops, all with the same PCMCIA 
card. The card used was a Linksys "Combo PCMCIA Ethernet Card", the box 
says it is the Model EC2T. It is available at CompUSA for normally about 
$40, but I picked up two of them several months ago for $20 each when they 
were on sale.
Each comes with a disk of drivers, an enabler for the socket driver, and a 
dongle that will accept either a CAT 5 cable or a BNC coax plug. They all 
worked with CT and K1TTT's ethernet drivers; time from the box to the 
network was about 30 min per laptop.
I can recommend these, and I know they work with at least 4 different types 
of laptops.
>From  Brian McGinness N3OC   n3oc@wirelessinc.com
LINKSYS! All the various linksys PCMCIA ethernet cards have working 
DOS enablers and packet drivers, which you have to have to run the card 
under DOS with CT! And they are only $39...
I suggest to anyone to avoid the hassle of finding both the dos 
enabler and packer driver to buy the linksys card, either the 10mb or the 
10/100 one.
Most of the V26B lan uses thiy type of card.
Available at compusa, etc.

CTwin uses a different default setup from what nettsr normally

uses.  The nettsr command line has to look like this:


Nettsr 100 3030


To be able to talk with ctwin.


Note that the port (3030) is different than the default (9870) that nettsr

Assumes.  Also CTWin uses as the broadcast address so the

Mask won’t do anything.  This also prevents subnetting CTwin networks on

The same network segment.