Notes on the use of NET with Satellites
(A beginners Guide to PE1CHL NET)
David Medley KI6QE
INTRODUCTION
Many of us have heard or read about a program called TCP/IP and
most of us ordinary mortals have been perplexed or even
intimidated by what we have seen or read.
So let us begin this discussion on the right foot by saying that
although PE1CHL NET is a variant of TCP/IP it is really not
necessary to know anything about it to use this excellent piece
of software to enhance our enjoyment of our satellite operations.
The few things we do need to know will be explained in the
following pages in terms which, hopefully, will be understood by
anyone interested. Those with PhD degrees and other Technical
types need read no further as you will not only be bored but you
will not learn anything you don't know already.
WHAT IS TCP/IP
The common definition says that TCP/IP is a set of protocols
developed to allow cooperating computers to share resources
across a network. Very clear Right ? Wrong, we still don't know
what it is. Well lets try again. A protocol is a set of
specifications which allows a software programmer to write a
program which does something special such as manipulate files.
So TCP/IP is a program which collects together a series of
programs which allows computers to work efficiently in a network.
It also allows your computer to do specific things without being
hooked into a network so from here on we are going to forget
about networks and all the theory and big words which go with
network operations. We still don't know what TCP/IP really means
and I am not going to divulge this secret because it is closely
guarded. All I can tell you is that TCP and IP are two protocols
which have something to do with the provision of services to the
network and as this has nothing to do with this discussion lets
forget it.
WHAT IS FTL0
OK more totally confusing mnemonics but this one we can explain.
When Jeff Ward (G0/K8KA) and Harold Price (NK6K) prepared the
protocol for the PACSAT system they called it "FILE TRANSFER
LEVEL ZERO" which is now commonly known as ftl0 (lower case).
This is starting to make sense at last and this describes what PG does,
transfer files. Now we are getting somewhere and the light is dawning.
What has this to do with TCP/IP and PE1CHL? Well what Rob
Janssen(PE1CHL) did was to take the TCP/IP NET (Rob is a
professional in these things and understands them) and add ftl0
to all the other protocols. What this does is allows us to do all
kinds of neat things with satellites on a stand alone basis or if
we are so inclined to hook into a TCP/IP terrestrial network.
Of course there is more. What about the broadcast facility which
many of us have learned to use and enjoy via PB. Well
there is a protocol which describes this and Glory Be it is
called BROADCAST. So Rob put this in NET as well so for the rest
of this document we are going to talk about some simple
applications of ftl0 and broadcast as applied to UOSAT3, also
known as uo14.
PRELIMINARIES
All this is well and good but what has to be done first before we
can even think about satellites and files and so on. I thought
you might ask this question so lets provide some answers.
The software program you need is called PE1CHL NET but will
appear with names like PE91005.ZIP. You will find it on uo14 from
time to time or you can get it from a friend or whatever. It is
free ware and yours for the asking. If all else fails send me a
formatted 720K or 1.2Mb disk with a mailer and enough return
postage and I will mail you the latest version I have.
You should also look for a file called "HISTORY" which will be a
great help to you later on but will confuse you totally until you
have read and understood this enlightening document.
First thing you do of course is to unzip or unarc the file and
this will give you at least three files. These will be called:-
NET.EXE
AUTOEXEC.NET
ONEXIT.NET
NET.EXE is the file which starts and executes the NET program but
it will only do this to your satisfaction after you do some
mysterious and magic things with AUTOEXEC.NET as well as teaching
your TNC to behave in ways which it may not have been familiar
with up to this point or at least you may not have been familiar
with. The TNC is probably smarter than you at this time but we
are going to change that.
A sample of AUTOEXEC.NET will be found at Appendix A and you
should follow it with the ensuing text.
The following discussion assumes that NET will be configured for
UO14. The datalink to the computer will be 19,200 baud and the
radio link 9600. Your TNC/9600 modem will be connected to COM1.
This is a long and perplexing document and is not particularly
friendly mainly because, up until right now, there has been no
other documentation. We are going to go through this item by item
and make everything friendlier (I hope).
It starts off just fine.
# PE1CHL-NET configuration file for the PC.
The # at the start means it is a comment or REM and so the computer
ignores all lines starting with #. You should not ignore them however.
Just make sure your version says PC and not ATARI or some other thing
you don't have. Of course if you don't have a PC then you have another
problem which I can't help you with but nevertheless much of what
follows is probably quite applicable and may even be helpful.
The next line says:
# insert your callsign (in lower case) etc.
Do just what it says. For our application it does not matter if
you use upper or lower case but it is important if you want to
use TCP/IP later. So do it now just in case.The line it is
referring to is:
setenv CALLSIGN ${CALLSIGN-ki6qe}
DO NOT CHANGE ANYTHING except the callsign (in lower case of
course).
Next we come to:
# COM1 connected to NB96 modem(9k6)
# Setup COM1 (second line) and COM2 (first line). don't change
parameters.
No I have not made a mistake. COM2 comes before COM1. You will
notice that the COM1 line has been REMed out with a # because we
are keeping this simple with only one TNC connected. Aha you say
but I want to connect my TNC to COM1. OK you can do that but you
must interchange the lines and the numbers 1 and 2. Your lines
will now look like this:
#attach com 2 ax25 psk 144 4800 n $CALLSIGN-2
attach com 1 ax25 9k6 256 19200 n $CALLSIGN-7
Note that 9k6 is a mnemonic for our TNC and we are going to use
that quite often. There is no magic in 9k6. If you don't like it
use something else, but be sure to change it wherever 9k6 appears.
(A big deal is made above of the order of COM1 and COM2. Actually
it is not a big deal and really doesn't matter in most
applications. You might run into a case later where it is
important so it is recommended you do as suggested above.)
We now we come to:
# AX25 configuration.
We all remember that AX25 is the protocol for normal packet
operation don't we ? We have puzzled about and wrestled with
Parameters ever since we started into packet radio. Some are more
important than others. Here we will see that we can understand
the first few lines which start with ax25 digipeat on. Similarly
the next four are in plain English and we can look these up in
our manual if we have forgotten. But please do not change these
unless you understand exactly what you are doing. Now the next
four lines appear to be secret as they set four parameters called
t1 t2 t3 and t4 and you won't find these in your manual, at least
not like this. But I am going to let you into the secret so long
as you don't change the numbers. Here is what they mean:
t1 is the retry timer. You know it as FRACK.
t2 is the response timer or RESPTIME.
t3 is the keep-alive timer or CHECK.
t4 is the idle timer. This is like the TIMEOUT in your local BBS
where it drops you off if you don't type something in a given
period of time.
Actually none of these are used by ftl0 but they are used by
AX25. So if you ever want to use NET for ordinary packet then you
will have set these as you would normally.
So now you know and won't need to ask any questions will you ?
ax25 window 2048.
This is the number of bytes that can be received and buffered on
an AX25 connection before the program sends RNR. Yes I do know
what that means, Receive Not Ready.
Now we come to:
#Misc settings.
Some are obvious, some obscure to say the least.
escape F10 means what it says. Use F10 to escape.
flow on.
If you don't know what this means and want to, read your TNC
manual.
log c:\net\netnew.log simply sets up a DOS path for a log file.
setenv PROMPT "[use EXIT to go back to NET] ${prompt-$p$g}
We are all used to EXIT with SHELL and the $p$g prompt most of us
use with our DOS.
Now the mysterious KISS mode. We find a line:
# KISS and AX25 stuff for each TNC connected.
Here we only have one TNC so we will only have one set of
parameters. You will note the others have been #ed out. (Pounded
out). You must remember to put your TNC in KISS mode before
running this program. We will discuss KISS more in a minute. The
parameters should all be familiar except perhaps ax25 persist.
Again it is not important for satellite full duplex operation but
is important for half duplex packet. (See below).
Now we come to the concept of virtual ports. We have already set
up COM1 for our TNC so what are all these other ports. Well they
are not really necessary for our satellite work but we might as
well try to understand what they are for. The NET program has
within it the ability to divide its attention between several
connectees coming in on our COM1 port and performing different
functions. Each function is associated with a separate virtual
port and there is a different SSID for each of these ports. For
example an external station can use your station as a digipeater
through virtual port 1 using the SSID of 3. (KI6QE-3 for
example). Deeper discussion of virtual ports is beyond the scope
of this document.
Now we are getting to the nitty gritty and something is starting
to happen. We see:
# initialize KISS TNC on 430.
But would you believe it here is another set of secret codes.
What in the world are params 1 through 5. They sure look
important. And indeed they are and here is the decode:
Param 1 is TXDELAY.
You may need to experiment with this as it depends on the type of
equipment you are using. Values around 50 have been found useful.
Param 2 is p-persistance. This together with slottime
is a newer and better way
of performing the function
of DWAIT. DWAIT should be 0
Param 3 is slottime.
param 4 is holdtime
param 5 is fullduplex (Yes/No) If you do not have
fulldup on you will never
transmit. Very frustrating.
The next five commands start the servers for the virtual ports
discussed above:
ax25 start bridge.
This starts a conference bridge on virtual port 4.
ax25 start mheard.
This starts the mheard (Calls heard) function on virtual port 3.
ax25 netdigi. This starts the digipeater we mentioned above on
virtual port 2
ax25 start tnc "= Connect Text =" . This starts a "tnc", where
you can be connected.
ax25 start tnc2 3=144 4=430. This starts a TNC emulator which is
beyond the scope of this discussion.
Actually you can #out all these AX25 functions if you are sure
you may never need them. Best advice is to leave them in. They
won't do any damage.
(If you want to see what they are all about in a practical sense
and after you have got the program up and running, you can
connect to NET (if you have another packet system) and play with
these functions.)
Finally we have to describe what it is we really want to do. In
this case we would like to access UO14 for all the functions of
the ftl0 protocol and we would like to receive and instigate
broadcasts.
broadcast start "\net\bcst"
broadcast server uo14 9k6 uosat3-11 256 2 4 1 3 pblist
These are the lines which set up the Broadcast function.
ftl0 homedir "\net\ftl0"
ftl0 server uo14 9k6 uosat3-12 256 2 4 1 3 bbstat "Open"
These are the lines which set up the ftl0 function.
In each case the first entry specifies a path to a directory in
which the relevant files will be found.
The second line describes the "server" which will perform the
functions.
Now a word about servers. We can't quite get away from TCP/IP
talk. A server is the hardware and associated software which is
going to carry out the specific function. The NET package
provides both servers (services) of its own, as described
above, and allows access to other servers like the UO14 ftl0
server. The "ftl0 server" commands provide the information it
needs for that, and gives a handle ("uo14" in this case) for
later reference.
ftl0 server uo14 9k6 uosat3-12 256 2 4 1 3 bbstat "Open"
This says that we are going to ask uo14 to perform ftl0
functions. It reminds the software that uo14 is 9600 baud (9k6)
and that its callsign is uosat3-12. 256 indicates packet length.
When you finally get around to loading NET it is going to wait
until it detects a bbstat "Open" frame from uo14 before it does
anything. More on this later.
Oh Boy now we have got to the end of that we should be able to
start something useful.
STARTUP
OK now you have completed the changes necessary to autoexec.net
but there are two more things to think about before we can
actually load the program.
First the TNC. Net is written for KISS mode TNCs and you need to
be sure that your TNC is capable of this mode and then to put it
into KISS. (KISS means "Keep it simple Stupid" but whoever
devised this mnemonic must have had a strange sense of humor. It
is anything but simple, at least to us mere mortals.)
Actually it is simple as some regard the KISS protocol as too
simple but where the confusion arises is for us to distinguish
between conv trans and kiss and how to get our TNCs into and out
of these modes. Perhaps a few simple words might be helpful.
Conversational Mode (conv) is where you talk to the TNC to give
it commands. You cannot talk to a connected station when the
TNC's prompt says cmd.
Transparent Mode (trans) is when your TNC is transparent to you
and you can talk to someone you are connected with. You cannot
give your TNC commands when in the transparent mode.
To get from transparent to conversational mode is usually no more
than cntrl-C and typing trans when at the cmd prompt has the
reverse effect.
Now KISS. When in KISS mode the TNC is transparent like in trans
but it passes through binary data to the computer without much
manipulation such as converting it to ASCII.
Older TNCs such as TNC1 and early PacComm and MFJ units did not
have KISS capability. Read your manual carefully to insure you
have a KISS TNC. If you have an AEA TNC you are probably in good
shape but there are a couple of tricks as we will see in a
minute.
Lets assume we have a TINY2 (a TNC-2 close clone) and a PC clone
computer. First we need a communications program such as PC-TALK
or better PROCOMM. Load this and be sure it is configured for the
port and speed we set up in AUTOEXEC.NET. (Remember we set the
speed at 19,200 and the Port at COM1). Turn on the TNC and you
should get a regular sign on message. Now type KISS ON and you
will see a cmd. prompt if all is well. Now type RESTART and you
will see nothing on the screen. In fact if you try to type
anything nothing happens. This is as it should be because your
TNC is in KISS mode which means that it is virtually transparent
to you and does not want or need to talk to you anymore.
If you have an AEA TNC, PK232 for example, there is one thing you
should know. As soon as you type KISS ON it becomes dumb and won't let
you type RESTART. Do not worry, it has done all this for you.
Just carry on as above.
If it says Eh? or What? when you type KISS ON your TNC does not have KISS
mode. If you are lucky all you will need is some updated firmware.
Contact the TNC manufacturer about this.
Another little matter which is confusing sometimes. If your TNC has a
battery in it it will remain in KISS mode for the life of the battery.
Turning it on and off a zillion times will not get it out of KISS
mode. Nor will RESET. So once you have it in KISS you do not have to
go through all the stuff above each time you turn it on.
On the other hand maybe you want to use your TNC in another mode
sometimes and it is pretty infuriating to have to take it out of the
cabinet, remove the battery jumper, wait X number of minutes, replace
the jumper etc. No no you do not have to do this. Buried inside your
manual somewhere you will find the secret of getting out of KISS. For
the TINY2 what you do is:
1. Depress NUMLOCK on your keypad.
2. Hold down ALT and type 192 on the keypad.
3. Release ALT
4. Hold down ALT and type 255 on the keypad.
The TNC will then reset, with the sign on message and default
parameters and return to COMMAND mode.
Now exit from PROCOMM (Alt-X) and change to whatever directory
you have NET.EXE in. NET is recommended.
Resist the temptation to type NET at this time because if you do
you will get a screen full of moderately unintelligible messages
which will dismay you somewhat. On the other hand if you feel
adventurous , try it. You will end up with an enigmatic prompt
which says net>. Type EXIT and you will get back to the NET
directory. What we have not done yet is to load the port driver
and for this discussion we will use MBBIOS which you should have
found among the files that came with PE1CHL.NET. You will also
find a file called MBBCONFG. This program will allow you to set
up drivers for up to four COM ports and is tricky in the extreme
for us ordinary folk. However if we only need one or two COM
ports it is quite benign. Type MBBCONFG and you will get a fairly
explanatory screen which should look something like this:
SLOT COM# IRQ SLOT TYPE
---- ---- --- -------------------------------
1 1 4 IBM Async card addressed as COM1
2 2 3 IBM Async card addressed as COM2
3 Slot is unused.
If this is what you see and if you have COM1 and COM2 active in your
machine you are lucky so hit F10 and forget about it.
If you do not have COM2 then enter a 2 in the box at the bottom of the
screen and hit enter. You will be confronted with a very puzzling
screen but not to worry if we only need to get rid of COM2.
Right at the top in the menu you will see an item A. Slot is unused.
Simply enter A into the highlighted box and hit F3 twice and you will
be back to the NET prompt.
If you want to do something more complicated like set up COM3 and
COM4, good luck. This is beyond the scope of this dissertation.
Now type MBBIOS and your machine will respond with a nice polite
message which says "MBBIOS loaded and ready."
When you have finished running NET and want to do something else
it is important to unload MBBIOS. You do this by typing
MBBIOS /U
and it will again respond with a nice polite message which says:
MBBIOS successfully unloaded.
If you fail to do this and try and run PG.EXE for example you
will unpredictable and usually unwanted results.
There are several other port drivers which may be used and are
less touchy than MBBIOS. One that will be mentioned here is
X00.SYS. This has to be installed at startup of your computer by
including this line in your config.sys file:
device = X00.sys E 2
The big disadvantage of this driver is that to unload it you have
to take it out of the config.sys file and reboot your computer.
Not always convenient and like MBBIOS, if you try and run
software which uses I/O functions you will run into trouble.
THE NET PROGRAM
NOW at long last you can type NET without incurring the wrath of your
machine.
After a short while you will see a Commercial telling you about the
nice folks who prepared this magic and then a simple prompt which says
net>
At this point this program is somewhat unfriendly and the remainder of
this document will try and help you make it a friend for life. You
can, of course, type HELP. It will respond to this with a screen full
of TCP/IP commands. Just that. No explanation. HELP (Command) does not
do much to alleviate this situation but (Command)? sometimes
gives you some rather terse reminders. However be not dismayed
because there is now a world of data magic awaiting your
commands.
If you look carefully at this HELP screen you will see ftl0 and
Broadcast included therein. These are the commands we are going to use
and you can ignore all the others.
Now type ftl0 (Enter). Your machine will respond with a message which
says "ftl0 takes at least one argument". OK lets give it an argument.
Type ftl0 ZZ (Enter). Your machine will respond with this message.
ftl0 sub commands: cancel directory download homedir kick post status
trace and upload.
Now it has condescended to tell us a little more about what it wants
so let us explore further.
BASIC OPERATIONS
Directory
The first thing we must understand about NET is that it is a real time
on line type program. It works with a satellite, in this case uo14, so
we are not going to see much activity unless signals are being received.
It will not even activate your transmitter unless the satellite is in view.
Well the first thing we need is a directory unless we already have one
from PG. So let us consider a command like:
ftl0 dir uo14 t KI6QE 9111111230
This is not so bad. ftl0 is the protocol, dir (Directory),uo14 is the
server, t(to), KI6QE (call sign), 911111230 (Hightime or date/time in
ordinary language).
After you type this in you will find that nothing will happen for a while.
DO NOT TYPE IT IN AGAIN. This will only result in the command
being executed twice. If you must type something to boost your
morale try:
ftl0 status uo14
and the computer will respond with the command you typed in
above. This means that it has got the message and wants to be
left alone.
This is useful to be able to confirm that it has got a batch of
stacked commands as we will see below.
Do not be alarmed. Nothing is supposed to happen until NET
detects a BBSTAT "Open" frame. As soon as this occurs you will
see the BBSTAT message on the screen and if there is a free slot
available NET will attempt to connect to UO14. As soon as it
connects it will ask for the directory of Private Messages to
KI6QE from the time indicated above. It will then proceed to
download this directory and place it in a file called dirfile.dl
and then disconnect. Unfortunately it does not tell you what is
in the directory at this stage so we have more work to do. Now
among the TCP\IP commands we have SHELL which allows us to exit
from NET WITHOUT UNLOADING IT and to execute commands from DOS.
We can read the directory by using PFH or a little more elegantly
by writing a little batch file to do this. Here is a sample.
File LISTDIR.BAT
pfh -c
c:\net\ftl0\uosat\dirfile.dl pfh -d
c:\net\ftl0\uosat\dirfile.dl > dir14.1st jtedit dir14.1st
This will put on the screen the most recent directory, with the most
recent entry first just by typing listdir ( jtedit is a little screen editor.
You can use any one you wish). After you have done this and noted the file
names, type EXIT to return to NET.
Other possible directory commands include:
ftl0 dir uo14 t *KI6QE* 9111111230
This will get multiple address files which include KI6QE as well as
files just addressed to KI6QE
ftl0 dir uo14 t ALL 9111111230
This will get files addressed to ALL
Uploading
To upload a file we must have it already prepared with the PACSAT header
(use PFH or PFHADD) and placed in the directory c:\net\ftl0\uosat3.
If this file is named CA1410T1.OUT, then the appropriate command is:
ftl0 upload uo14 c:\net\ftl0\uosat3\ca1410t1.out delete
If you have several files to upload you can type the instructions in one
after the other before the satellite comes over the horizon. In fact it is
better to do this to save time during the actual pass. NET will listen for
an OPEN frame and upload all the files you have "stacked" commands for. You
will be able to see its progress on the screen. After the file has been
uploaded it will be deleted from your disk. If you do not want to do this
simply omit the word "delete".
Downloading
To download a file you must first get a directory (see above) and note the
filenames of those files you wish to download. Let us say these are 33e0 and
33dc. You would stack two commands like:
ftl0 download uo14 33e0
ftl0 download uo14 33dc
This will download as many files as you have stacked with a single connect.
Broadcasting
A much better and faster way to download files is by Broadcasting. (Just like
PB). To do this we use the BROADCAST command like:
broadcast download uo14 33e0.
Instead of using the ftl0 protocol we are using broadcast. Use this as much
as possible in place of download as it does not require a connect and
therefore does not occupy a channel thus allowing others to use the satellite
while you are still getting your files.
Summary to date.
Now we have the basics and can go ahead and use UO14. We could have included
all of the above in one set of commands like:
ftl0 dir uo14 t *ki6qe* 9111141230
ftl0 upload uo14 c:\net\ftl0\uosat\ca1401t1.out
broadcast download uo14 33e0
broadcast download uo14 33dc
You can do this long before the satellite comes over the horizon and it
will execute all of the above, even if you are not in the shack but rather
in the sack.
One problem, of course, is the directory. The above assumes you have obtained
the file names 33e0 and 33dc from a directory obtained in a previous pass.
We will address and solve this problem as we get into a discussion on
automation.
AUTOMATION
One of the great things about NET is its great flexibility and really
unfathomed potential. We can see from the discussion above that we have
already achieved a degree of automation but we still have the problem of
the directory which needs us to be there, SHELL out to get the file names,
and then return and enter more commands while the satellite is in view.
This is a pain, especially for those of us who are poor typists and it
generally results in having to follow two passes and to use more
satellite time than we need.
So what can we do without re-writing the software ? Well we have two very
powerful tools at our disposal. Batch Processing and a TCP\IP command
post. Batch processing we know about (more or less) but few of us have
realized its enormous power and potential and you do not have to be a
PhD or even a programmer to use it. We can write very simple little
routines which will do gigantic tasks. We already gave an example above
which co-ordinated two large software programs to do a needed task without
us having to do a lot of typing and remembering complicated commands.
If you look at the very end of the example in the appendix you will see
a line which you have probably been wondering about. It says
source /net/commands.net
What this means is that there is a file, commands.net, in the NET
directory which contains a bunch of stacked commands which we may
have prepared with a word processor or even by some other piece
of software. As soon as NET is loaded this tells it to look in
this file and load the commands that it contains. This now opens
the door to preparing sets of commands even when NET is not
loaded. A software module called "OUTMESS" which takes message
output from a Bulletin Board ,prepares the messages for upload
and writes the appropriate commands.net file is used extensively
in the Satellite Gateway System and will be described in another
document.
But we still have this pesky Directory and Download problem. This
is more complicated and takes more TCP\IP stuff to do it.
DOWNLOADING
The last line in the COMMANDS.NET file will look like this:
ftl0 post uo14 source dir
Now let us see what this means and does. First note that this is
the last of the stacked commands and NET will not execute it
until all commands above it have been completed. Remember that
one of these was a directory command for all private messages
addressed to you.
As soon as the stacked commands have been completed NET
disconnects from the satellite and looks for a source file called
"DIR" and executes the commands it finds there. This is DIR:
shell /c clear14.bat
source request
ftl0 post uo14 source mail
What this does is to SHELL to DOS and run a batch file called
clear14.bat. This uses two other programs called STAFIND and PFH
and some DOS stuff to analyse the Directory just downloaded and
write a new file called REQUEST. This will look like this:
ftl0 upload uo14 3693
ftl0 upload uo14 35f6
NET then executes these new commands by downloading all the files
that were in the directory, disconnects once more, and goes to
the next "POST" command in the last line of DIR. This points now
to another little source file called "MAIL" which looks like
this:
shell /c inmess.bat
ftl0 post uo14 #
So we execute another SHELL to DOS and run yet another batch file
called INMESS.BAT. This program uses PFH and PKUNZIP to strip off
the PACSAT header and extract the text (Messages) and consolidate
them into a file called MAIL-IN.FBB. Presto we have solved the
Download problem and all has been accomplished automatically.
The above is a synopsis of a quite complex process and more
detail will be supplied in another document which will describe
in detail the setting up of an automated packet gateway.
CONCLUSION
This should provide you with enough information to get PE1CHL NET
up and running and to perform the same tasks that you have been
doing with PG and PB. You may be then tempted to try some
automation and it may also whet your appetite enough to explore
more complex applications and to venture into the world of
TCP/IP.
To become really familiar with NET you should now start reading
the HISTORY file which hopefully will now be a little easier to
follow and understand. If you run into any problems or things you
do not understand ask for HELP!!!! There are lots of people out
there who will come to your aid including PE1CHL himself.
Now as a final and exciting finale to this treatise I am ready to
announce that after countless hours of study and research I have
finally found out what TCP/IP stands for.
TCP = TRANSMISSION CONTROL PROTOCOL
IP = INTERNET PROTOCOL
Isn't that exciting!!!!
ATTACHMENT A
# PE1CHL-NET configuration file for PC as amended for KI6QE
#
# insert your callsign (in lowercase) instead of the callsign below.
# don't add an SSID here, and change only the part between - and }
#
setenv CALLSIGN ${CALLSIGN-ki6qe}
#
# COM1 connected to NB96 modem(9k6)
# Setup COM1 (second line) and COM2 (first line). don't change parameters!
#
#attach com 2 ax25 psk 120 4800 n $CALLSIGN-7
attach com 1 ax25 9k6 240 19200 n $CALLSIGN-2
#
# AX25 configuration
#
ax25 digipeat on
ax25 maxframe 4
ax25 paclen 128
ax25 pthresh 64
ax25 retry 10
ax25 t1 15000
ax25 t2 1500
ax25 t3 1800000
ax25 t4 900000
ax25 window 2048
#
# Misc settings
#
escape F10
flow on
#
log c:\net\netnew.log
setenv PROMPT "[use EXIT to go back to NET] ${PROMPT-$p$g}"
#
# KISS and AX25 stuff for each TNC connected
#
mheard 9k6 23
mheard psk 23
#mode 430 datagram
#mode 144 datagram
#ax25 digipeat 430 gate
ax25 digipeat 9k6 gate
ax25 persist 9k6 128 5 64 60 900
ax25 persist psk 128 5 64 60 900
ax25 digipeat psk gate
# AX25 ports. 1=TNC 2=NetDigi 3=MHEARD 4=Bridge 5=TNC2 6=MBOX
#
ax25 port 1 conn $CALLSIGN
ax25 port 1 digi $CALLSIGN-3 psk gate
ax25 port 2 digi $CALLSIGN-8 9k6 gate
#ax25 port 3 conn $CALLSIGN-3 144 multi
ax25 port 3 conn $CALLSIGN-8 9k6 multi
ax25 port 4 conn $CALLSIGN-6
ax25 port 5 conn $CALLSIGN-12
ax25 port 6 conn $CALLSIGN-1
#
# initialize KISS TNC on 430
#
param 9k6 1 50
param 9k6 2 64
param 9k6 3 30
param 9k6 4 3
param 9k6 5 1
#
# initialize KISS TNC on 144
#
param psk 1 50
param psk 2 64
param psk 3 30
param psk 4 3
param psk 5 1
#
# now we can safely start all servers
#
ax25 start bridge
ax25 start mheard
ax25 start netdigi
ax25 start tnc "= Connect Text ="
#ax25 start tnc2 3=144 4=430
#
broadcast start "\net\bcst"
broadcast server uo14 9k6 uosat3-11 140 2 4 1 3 pblist
broadcast server ao16 psk pacsat-11 244 2 4 1 3 pblist
ftl0 homedir "\net\ftl0"
ftl0 server ao16 psk pacsat-12 130 1 6 1 3 bbstat "Open"
ftl0 server uo14 9k6 uosat3-12 140 2 4 1 3 bbstat "Open"
ftl0 server lo19 psk lusat-12 130 1 6 1 3 bbstat "Open"
ftl0 trace 00ff
at 06:00 source \net\at0100.net
#at 18:30 source \net\at0100.net
source \net\commands.net