Date: Tue, 14 Dec 93 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #322
To: tcp-group-digest


TCP-Group Digest            Tue, 14 Dec 93       Volume 93 : Issue  322

Today's Topics:
        Need help on config. of X1J for IP routing and NETROM
                               Networks
                      telnet & who does the echo
                    UDP Locking Things Up (3 msgs)
                      wampes S.F with DK5sg bbs

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 13 Dec 93 19:50:58 mdt
From: ka7oei@uugate.wa7slg.ampr.org
Subject: Need help on config. of X1J for IP routing and NETROM
To: tcp-group@ucsd.edu

The new network for the Salt Lake City area packet WAN/LAN is going online
over the next several months.  We are planning to use the old TNC2 clone
for the router.

This network consists of a number of 1200 baud, 2 meter nodes (the interface
for most of the users) strategically located both geographically and 
frequency-wise to minimize the number of hidden terminals, as well as overall
minimize the damage that a hidden terminals may cause.  These 2 meter
'nodes' are interconnected by a 70 cm 9600 baud simplex channel in the 420
MHz range.  All nodes on the intertie channel are located such that they
all hear each other and there are thus no hidden terminals.

At several key points in the system, there are other ties to other parts of the 
network.  At some points there are ties to the local 9600 baud user channels
as well as the 9600 baud repeater, and ties into the high speed backbones
(i.e. 56 kbaud and higher)

What we need to do is set up the X1J nodes for IP routing among all of the
nodes and set up the limited ARP to serve as best it can.

Both the NetROM and the IP routing need to be configured to route properly,
as well.   For instance, between the 2 meter 1200 baud nodes (which are tied
together at 9600 baud) the route that it *should* always use (unless it is
down, of course) is the 'node intertie' 70cm 9600 baud frequency.  It
should *not* try to route via the 9600 baud users channels, the repeater,
or the 9600 baud BBS interties unless the primary route becomes unavailable.

The question is:  From those who have practical experience in configuring 
X1J and using its various features, how would one configure the nodes
in such a network?

<Clint>

clint@uugate.aim.utah.edu
ka7oei@uugate.wa7slg.ampr.org

------------------------------

Date: Mon, 13 Dec 1993 07:51:35 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: Networks
To: klarsen@acca.nmsu.EDU

The purpose of the tcp-group mailing list is for discussions of advanced
ham radio packet networking.  That means that we're a group of people
who believe that what we have isn't good enough and has to be made better.

If you don't like the discussions here, please unsubscribe.

 - Brian

------------------------------

Date: Mon, 13 Dec 93 7:55:39 MST
From: dlf@phx.mcd.mot.com (Dave Fritsche)
Subject: telnet & who does the echo
To: tcp-group@ucsd.edu

Howdy,

I'm having quite a bit of fun here with Wampes on my Linux box.  But my
users aren't able to enjoy it quite as much as I am, since they aren't
sitting at the console.  Normally, when a NOS user telnets in, the NOS
side does local echo, and bags up all the keys hit until a <CR>.  Pretty
much everything anyone would want to play with on a Linux machine, makes
the cavalier assumption that the application will receive every keystroke
as it happens.  "elm" is one of those applications that once you get in,
you can't get out if you have to send a <CR> after each command key.

The question is, what needs to be configured at each end to make it
work?  Obviously you want Linux to do the echo, not the NOS side, and
I presumed that all one needs to do is set "echo accept" on the NOS
side.  That alone didn't seem to do it though.  We closed the session,
set "echo accept", then telnetted back in.  This was NOS v901130.  I've
also had someone try it with a (1.07) rev of wg7j.  Any ideas?  Maybe
the telnet negotiating in wampes is broken (I'm using the 10/01/93
version).  Not sure how to go about debugging this one.

73 . . . Dave Fritsche (wb8zxu)
dlf@phx.mcd.mot.com (Tempe, AZ)

------------------------------

Date: Mon, 13 Dec 93 10:29:09 CST
From: jwhite@cuscus.mecc.mn.org (Jeff White)
Subject: UDP Locking Things Up
To: ssampson@sabea-oc.af.mil (Steve Sampson)

Steve Sampson Said:
>
>
>I've seen this problem I think when I was using DNS to look up a name that I
>just typed in on the mailbox.  The name wasn't in the table and everything
>locked up waiting for the name to be resolved or timeout.  In your case you
>seem to be indicating "timer" and you have a Timer Listener process.  Are these
>two the same? What's a timer listener and do you really need it.  If not,
>maybe the timer is just a side affect of the DNS problem I saw.  Probably
>a DNS table design or record error.

I have had a similar problem with JNOS.  It appears to be happening in
the domain lookup when smtp fires up.  The timer process gets hung up
waiting for some event, and stops running.  This causes all sorts of
havoc, as you can imagine.


-- 
Jeff White, N0POY                       MECC Senior Programmer 
INTERNET:  jwhite@hydra.n0poy.ampr.org  ICBMNET: 45^2', 93^13'
SKIPNET:   n0poy@tcman.#msp.mn.usa.noam USENET:  jwhite@cuscus.mecc.mn.org
PHONENET:  612-569-1714

------------------------------

Date: Mon, 13 Dec 1993 16:14:12 -0500
From: "Brandon S. Allbery" <bsa@kf8nh.wariat.org>
Subject: UDP Locking Things Up 
To: tcp-group@ucsd.edu

In your message of Mon, 13 Dec 1993 10:29:09 CST, you write:
+---------------
| Steve Sampson Said:
| >I've seen this problem I think when I was using DNS to look up a name that I
| >just typed in on the mailbox.  The name wasn't in the table and everything
| >locked up waiting for the name to be resolved or timeout.  In your case you
| >seem to be indicating "timer" and you have a Timer Listener process.  Are th
ese
| 
| I have had a similar problem with JNOS.  It appears to be happening in
| the domain lookup when smtp fires up.  The timer process gets hung up
| waiting for some event, and stops running.  This causes all sorts of
| havoc, as you can imagine.
+---------------

Oh-oh... we had this problem in JNOS with the "at" mechanism.  What it
amounted to was that a routine run in the timer proc's context (e.g. a timeout
routine) would try to do a sleep(), which would cause the timerproc to suspend
waiting for a psignal() to be sent by the timerproc...  I suggest you check
for the SMTP timer routine not trying to do timer-related operations from
the timer routine.

++Brandon
--
Brandon S. Allbery    kf8nh@kf8nh.ampr.org   bsa@kf8nh.wariat.org
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful development."  ---dmeggins@aix1.uottawa.ca
Do not taunt Happy Fun Coder. (seen on the Net...)

------------------------------

Date: Mon, 13 Dec 93 16:57:56 EST
From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
Subject: UDP Locking Things Up
To: jwhite@cuscus.mecc.mn.org, ssampson@sabea-oc.af.mil

What you are seeing is perfectly normal in a DOS nos enviroment. The
resolve code waits while it is getting a reply from either the local
domain cache, the domain.txt file or a remote DNS. If you send a mail
message or messages the lookup of the names can take a considerable
amount of time if the names are at the end of a long domain.txt file
OR if the DNS response time is long. 

This does not tie up nos. It just ties up the command session. Because
the resolve int this case is not done in a seperate session. In contrast
most other resolves, such as those in ping,ftp,telnet, are done in sessions.
While the resolve is going on you can hit F10 and go back to the command
session.

I have not looked at the smtp/bbs mail code but I do not see why this could
not be done in a session also, so that the command session could still run.
I never gave it much priority here. I have a fast system and the delays even
to my internet DNS are minor. 

For speed the key points are to keep you domain.txt file short and to have
the most used entries FIRST in the file. Also running the domain.txt file
in a ramdisk helps. To do this in JNOS, in your config.sys/autoexec.bat
configure a ramdisk, copy domain.txt to it, and tell nos in the nos.cfg
file to use the new disk for domain lookups.

If you are using a DNS and the lookup times are very long or unreliable
perhaps you should pick up the master domain file from ucsd and select out
the entries you use most often, keeping them in a local domain.txt file. Just
remember that the lookup is in your local cache and file first.

On the subject of domain.c, I have added a 'domain query <DNS> <HOSTID>'
which allows lookup at any DNS of a name which DOES NOT update the local
cache (or domain file). This is handy to see what a particuliar site
returns for a name.

Also a request was made to be able to 'ping' from a bbs login. I added this
and K2MF added pinging from the sysop exit of the BBS. You can now SEE the
response. 

Doug

------------------------------

Date: Tue, 14 Dec 93 01:45:27 CET
From: BARRY TITMARSH <BTITMARS%ESOC.BITNET@vm.gmd.de>
Subject: wampes S.F with DK5sg bbs
To: TCP-GROUP <TCP-GROUP@ucsd.edu>

Can anyone explain the format of the bbs/config file
is it hostname connect_mode ax25_call  or what ?

i have looked in the code bbs.c and can only see that the code looks for
spaces and a hostname ?
so the file should only need to be a list of hosts that connect with S.F
in tests i make on my home system this is the case.! but i cant seem to
figure out how to make the DK5SG-BBS startup and send OUT_GOING S.F mails
there are command line params in the code
bbs -d  for debug_mode
bbs -w [seconds]  for some delayed action ?
bbs -f host|-m ?? i think that is the kick to start off S.F to a host.
but unless i have some other config file missing or contents wrong all i get
is either a program stop at line 2951 or it just dont do anything.
I think the bbs must try to make an outgoing connect via wampes UNIX:/tcp/
.socket/netcmd=  in some way.
Could Mr D.Dyke DK5SG please explain? how.
or any other wampes + dk5sg bbs user that has it all working.! ;-))
Barry ...

------------------------------

End of TCP-Group Digest V93 #322
******************************
******************************