Date: Fri, 24 Sep 93 04:30:01 PDT
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 #247
To: tcp-group-digest
TCP-Group Digest Fri, 24 Sep 93 Volume 93 : Issue 247
Today's Topics:
ampr.org in San Jose, Ca (2 msgs)
Asking for NNTP Configuration Files
backoff bugs (3 msgs)
Oct 3: New England TCP/IP meeting, Nashua, NH
PMnos 1.1 (2 msgs)
PMNOS Version 1.1 (4 msgs)
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: Fri, 24 Sep 93 04:40:00 GMT
From: aa7tr@n7vvx.ampr.org
Subject: ampr.org in San Jose, Ca
To: tcp-group@ucsd.edu
Hello I'm looking for a host in San Jose, Ca.
My brother lives in Morgan Hill, about 15 miles to the south of San Jose
He would like to use TCP/IP but can find anyone that knows anything about
it. He has been looking for a node or router that user TCP/IP without
any luck.
Hope someone their can help.
Thanks
Bob Anderson
73
------------------------------
Date: Fri, 24 Sep 93 01:44:15 PDT
From: enge@almaden.ibm.com
Subject: ampr.org in San Jose, Ca
To: TCP-GROUP@UCSD.EDU
In <N7VVX0000029@bbs.net> aa7tr@n7vvx.ampr.org writes:
>Hello I'm looking for a host in San Jose, Ca.
>My brother lives in Morgan Hill, about 15 miles to the south of San Jose
>He would like to use TCP/IP but can find anyone that knows anything about
>it. He has been looking for a node or router that user TCP/IP without
>any luck.
> Hope someone their can help.
>Thanks
>Bob Anderson
>73
>
The closest TCP/IP node is the South San Jose switch at the IBM
Almaden site. It's on 145.75 Mhz. BBS activity for Morgan Hill
is on 144.99 Mhz.
Roy, AA4RE
Gilroy
------------------------------
Date: Thu, 23 Sep 93 19:19:24 CST
From: invitado@speedy.coacade.uv.mx (Cuenta Publica)
Subject: Asking for NNTP Configuration Files
To: tcp-group@ucsd.edu
If somebody has one please send it to me... Thanks a lot
de Roman
Roman Torres
Programmer
rtorres@duffy.coacade.uv.mx
------------------------------
Date: Thu, 23 Sep 93 10:40:34 CDT
From: bob@lachman.com (Bob Van Valzah)
Subject: backoff bugs
To: MIKEBW@ids.net
> Some NOSs unilaterally terminate a TCP circuit after a settable
> number of retries.
> . . .
> I am not sure that timing out TCP circuits is impossible to do in some
> intelligent way, but this method is obviously flawed. My thought is to
> have a log associated with each TCP session control block that holds
> the time of last transmitted or received frame. If the time since last
> activity exceeds some threshold, then reset the circuit. This would
> help system deal with the JNOS timeout scheme, and would prevent hosts
> from timing out and terminating sessions unilaterally.
I used to look at it this way too, but I think it was Bdale who
convinced me that such timeouts don't belong in the TCP layer at all.
The amount of time an application like SMTP is willing to wait might
be very different from one such as Telnet. Such "connection level"
timeouts should be recognized by the applications themselves.
When SMTP decides it's waited long enough, it should ask the TCP layer
to cleanly close down the sockets and reclaim the resources.
73, Bob, ke9yq
------------------------------
Date: Thu, 23 Sep 1993 12:24:31 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: backoff bugs
To: bob@lachman.com, tcp-group@ucsd.edu
I admit that I don't like the idea of timing out a TCP circuit. The goal,
however, is to deal with catastrophic situations where NOS is running out
of resources because lots of sockets are open which have been unilaterally
terminated at the other end. There are two possible outcomes of this:
NOS will run out of sockets and start refusing connections, or NOS will
run out of memory and crash. These conditions have nothing to do with
difference in how long telnet might wait as opposed to SMTP, as the times
at which I would have something trip off to close a session would be a
matter of hours or even days.
The situation now is that a lot of people are using variants of NOS which
time out a TCP circuit after some number of retries, and then just start
another TCP circuit. What I want is not some sort of method by which they
can do that -- there isn't one and they shouldn't do it -- but rather a
method by which the victim of this on the other end can avoid wedging.
The suggestion to incorporate PE1CHL's idea of terminating a passive TCP
socket if another TCP session is opened to the same socket from the same
host seems like it might be a good idea. For certain services which are
started automatically, such as SMTP, this might be a reasonable approach.
For other services which are usually started manually, such telnet or
FTP, this would probably not be a good idea, and would probably not be
necessary. Of course, binding the timeout/reset behavior to the TCP
socket number seems like a dangerous concept also, but I don't mean to
get a layered protocol religious war started.
-- Mike Bilow, mikebw@ids.net
N1BEE @ WA1PHY.#EMA.MA.USA.NA
------------------------------
Date: Thu, 23 Sep 93 14:13:49 CDT
From: andyw@aspen.cray.com (Andy Warner)
Subject: backoff bugs
To: MIKEBW@ids.net (Mike Bilow)
> I admit that I don't like the idea of timing out a TCP circuit. The goal,
> [...]
> matter of hours or even days.
So, add a watchdog timer to servers (like smtp & ftp). This has been
in unix versions for a very long while, it's not rocket science.
> [...]
> The suggestion to incorporate PE1CHL's idea of terminating a passive TCP
> socket if another TCP session is opened to the same socket from the same
> host seems like it might be a good idea. For certain services which are
> started automatically, such as SMTP, this might be a reasonable approach.
Please don't do this, when sendmail gets fired up on a unix box,
you'll have all kinds of connections going simultaneously, I'd hate
to see some "smart" routine in NOS figuring out that it could terminate
these extra connections.
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Thu, 23 Sep 1993 12:30:08 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow)
Subject: Oct 3: New England TCP/IP meeting, Nashua, NH
To: tcp-group@ucsd.edu, nos-bbs@hydra.carleton.ca
(Apologies to all who are not within close driving distance for sending
this meeting notice to the list, but you never know...)
The New England TCP/IP Association will hold its next meeting
on Sunday, October 3, 1993, at Nashua Memorial Hospital,
Nashua, NH. The meeting will begin at 1:00 pm and end not
later than 5:00 pm. For those interested, there will be an
informal lunch before the meeting in the hospital cafeteria,
beginning around 11:30 am.
Regular attendees should note the Sunday afternoon meeting
time, which is a departure from past NE TCPA meetings.
For information about the New England TCP/IP Association,
please contact me:
Amprnet: n1bee@n1bee.ampr.org
Packet BBS: N1BEE @ WA1PHY.#EMA.MA.USA.NA
Internet: mikebw@ids.net
CompuServe: >INTERNET:mikebw@ids.net
Fidonet: MIKE BILOW, 1:323/2
U.S. Mail: Forty Plantations, Cranston, RI 02920-5554
Voice tel: (401)944-3937
This meeting is being hosted by the Nashua TCP/IPers, courtesy
of Gary Grebus, K8LT. Directions are below. For further
information about the site or directions, please contact him
directly: glg@k8lt.ampr.org (Amprnet) or K8LT @
WA1PHY.#EMA.MA.USA.NA (Packet BBS).
-- Mike Bilow
President, NE TCPA
Directions to the NE TCPA Meeting
Nashua Memorial Hospital
Nashua, NH
(A map of the area in PC Paintbrush .PCX format is available for
FTP as ~/pub/nmhmap.zip at k8lt.ampr.org.)
***** From MA and points South:
Take I-495 to Route 3 North.
Follow Route 3 into New Hampshire.
Exit at Route 111 East (Exit 5E).
Follow the exit road to the stop sign.
Continue straight onto Kinsley St. (Follow the "H"ospital sign).
(continued; see "From Kinsley St." below)
***** From the North:
Take the Everett Turnpike South toward Nashua.
Exit at Route 111 East (Exit 5E).
Route 111 East crosses back over the Everett Turnpike and
becomes Kinsley St.
(continued; see "From Kinsley St." below)
***** From Kinsley St.:
Continue straight past St. Joseph's Hospital.
Turn right onto Main St. (about 1 mile). The hospital is at
this intersection.
Immediately turn left onto Prospect St.
Park in the parking garage on your right.
Enter the hospital through the main entrance, directly across
from the parking garage.
***** Talk-in
We'll be monitoring the 147.045+ repeater to help with directions.
(end)
------------------------------
Date: Thu, 23 Sep 93 16:35:54 EDT
From: n4clh@vnet.IBM.COM
Subject: PMnos 1.1
To: TCP-Group@UCSD.Edu
I have it up running on two systems. It appears to be working just like
the previous version. I am using OS/2 2.1. also noted PMail is updated.
73,
=> Bob - N4CLH @ WA4BRO.ATL.GA.USA.NA
=> amprnet - 44.36.0.120 (n4clh.ampr.org) Atlanta, GA.
=> internet - rwaustin@atlvm1.vnet.ibm.com
------------------------------
Date: Thu, 23 Sep 93 22:40:25 EDT
From: n4clh@vnet.IBM.COM
Subject: PMNOS 1.1
To: TCP-Group@UCSD.Edu
Hey Folks, this is good stuff for OS/2. I find it much smoother than the DOS
versions. It appears to be running faster. All the functions as before are
working. Pings a little slow on first set, but picks right up and goes. The
trace screen works fine. I have had it up and running for the week now, and
no crash. As for the STATUS giving files open, I did not think the latest
versions were giving the files thing anymore. Since PMNOS runs in its own
little world of OS/2, files open are of no concern. Memory sure isn't.
Walts update seems to be pretty crash proof(knock the wood).
Thanks Walt-
73,
=> Bob - N4CLH @ WA4BRO.ATL.GA.USA.NA
=> amprnet - 44.36.0.120 (n4clh.ampr.org) Atlanta, GA.
=> internet - rwaustin@atlvm1.vnet.ibm.com
------------------------------
Date: 23 Sep 1993 08:58:32 -0500 (EST)
From: Mike Murphree <mike.murphree@stpete.honeywell.com>
Subject: PMNOS Version 1.1
To: TCP-Group@UCSD.Edu
Has anyone else tried running the new version of PMNOS?
Once I got past all the command differences, I finally
got it running, but it is still not working properly...
If I attempt a connection or a ping to another station,
then a frame is sent out the TNC immediately, but trace
does not show the frame going out and the target station
never responds. This is over a known good path that works
fine under JNOS.
Anyone have any ideas?
******************************************************
* 73 de Mike, N4CNW@W4DPH.#TPA.FL.USA.NA *
* Amprnet: n4cnw@n4cnw.ampr.org [44.98.0.151] *
* Internet: mike.murphree@stpete.honeywell.com *
******************************************************
------------------------------
Date: 23 Sep 93 10:23:46 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: PMNOS Version 1.1
To: <TCP-Group@UCSD.Edu>
> If I attempt a connection or a ping to another station,
> then a frame is sent out the TNC immediately, but trace
> does not show the frame going out and the target station
> never responds. This is over a known good path that works
> fine under JNOS.
>
> Anyone have any ideas?
On JNOS, when I do a connect and then switch to the trace
session, I never see the initial connect request packet get
sent. It's a timing problem. I do see any retry, connect
request. Can you see and subsequent connect request get
sent out?
Also, on PMNOS in general.... is there a STAT command and
does it show you a list of open files like the DOS, JNOS
version does? Thanks.
73's de Jack - kf5mg
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386
------------------------------
Date: Thu, 23 Sep 93 15:18:42 est
From: kz1f@kz1f.hdn.legent.com (Walt Corey [44.104.0.23])
Subject: PMNOS Version 1.1
To: tcp_group@ucsd.edu
> Once I got past all the command differences, I finally
What command differences? Its identical to the earlier versions in that
respect, save bootp and bootpd.
> got it running, but it is still not working properly...
excuse me? Works fine here. trace shows all the packets flowing into or out
of the port. No problem with connects or icmp.
Walt
------------------------------
Date: Thu, 23 Sep 93 16:17:44 HST
From: tony@mpg.phys.hawaii.edu (Antonio Querubin)
Subject: PMNOS Version 1.1
To: TCP-Group@UCSD.Edu, mike.murphree@stpete.honeywell.com
> Has anyone else tried running the new version of PMNOS?
Using the same autoexec.nos file that I use for JNOS:
The mailbox 'operator' command causes a disconnect. Also, when going into the
conference mode from the mailbox, sometimes the connection is immediately
terminated, sometimes it'll work. However, an explicit
'telnet <local hostname> 3600' from the net prompt will work all the time.
Running OS/2 2.1 here.
Tony AH6BW
------------------------------
Date: Thu, 23 Sep 93 14:06:29 -0700
From: owner-tcp-group
------------------------------
End of TCP-Group Digest V93 #247
******************************
******************************