Date: Tue, 1 Jun 93 04:30:10 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 #141
To: tcp-group-digest
TCP-Group Digest Tue, 1 Jun 93 Volume 93 : Issue 141
Today's Topics:
Hints for Getting & Compiling NOS base code
SMTP Hangups with ICMP Unreachable Port/Network? (2 msgs)
TCP-Group Digest V93 #138
TCP Blimit
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: Tue, 1 Jun 93 9:57:58 BST
From: john <John.Heaton@nessie.mcc.ac.uk>
Subject: Hints for Getting & Compiling NOS base code
To: tcp-group@ucsd.edu
>To make a raw list of filenames from a directory under MS-DOS 5.0 or
>later, issue the DIR command with the "/b" switch. This produces a
>"bare" listing. For example, "DIR *.c /b > all_c.lst" will find all
>2of the *.c files in the current directory and put their names into
>file all_c.lst, one filename per line. This can significantly speed
>up the "co" processing discussed.
A much easier way is:
for %a in (*.c) do co %a
at the DOS prompt.
(It saves the mucking about with temporary batch files etc.)
>-- Mike Bilow, <mikebw@ids.net> (Internet)
> N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
John
--
John Heaton - NRS Central Administrator
MCC Network Unit, The University, Oxford Road, Manchester, M13-9PL
Phone: (+44) 61 275 6011 - FAX: (+44) 61 275 6040
Packet: G1YYH @ G1YYH.GB7PWY.#16.GBR.EU
------------------------------
Date: Mon, 31 May 1993 18:22:54 -0600 (CST)
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: SMTP Hangups with ICMP Unreachable Port/Network?
To: tcp-group@ucsd.edu
The scenario:
Using one PC (scratchy, running NUPOP) as SMTP client to send mail
through a second PC (marge, running NOS-9305xx) the SMTP server, routed to
a faraway address (computone.com, which is unreachable right now).
As soon as marge gets the "RCPT TO:<whoever@computone.com>", it goes off
in a tizzy trying to resolve computone.com. Even though it gets several
ICMP messages from our local domain serverS telling marge that computone.com
is unreachable, marge just sits there and keeps trying to resolve it anyway.
At least that's what it looks like from the traces.
Anyone had trouble with this one before? I'm still trying to figure out
where (if at all) the bug is. Ideally I guess, the resolver would respond
to the ICMP message and the mail would get bumped to the smart host or kept
around until the remote network is reachable again. Sugguestions?
- Erik "Why is it that when I send off a message saying the I finally
have a bug-free version, the message ITSELF triggers one?" Olson
---
Erik Olson (in lab) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Mon, 31 May 1993 18:22:54 -0600 (CST)
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: SMTP Hangups with ICMP Unreachable Port/Network?
To: tcp-group@ucsd.edu
The scenario:
Using one PC (scratchy, running NUPOP) as SMTP client to send mail
through a second PC (marge, running NOS-9305xx) the SMTP server, routed to
a faraway address (computone.com, which is unreachable right now).
As soon as marge gets the "RCPT TO:<whoever@computone.com>", it goes off
in a tizzy trying to resolve computone.com. Even though it gets several
ICMP messages from our local domain serverS telling marge that computone.com
is unreachable, marge just sits there and keeps trying to resolve it anyway.
At least that's what it looks like from the traces.
Anyone had trouble with this one before? I'm still trying to figure out
where (if at all) the bug is. Ideally I guess, the resolver would respond
to the ICMP message and the mail would get bumped to the smart host or kept
around until the remote network is reachable again. Sugguestions?
- Erik "Why is it that when I send off a message saying the I finally
have a bug-free version, the message ITSELF triggers one?" Olson
---
Erik Olson (in lab) erik@marge.phys.washington.edu
University of Washington olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405
------------------------------
Date: Mon, 31 May 1993 09:12:28 -0600
From: ke9yq@ke9yq.ampr.org (Bob Van Valzah, ke9yq)
Subject: TCP-Group Digest V93 #138
To: TCP-Group@UCSD.Edu
> Is anybody out there using 10Ghz microwave radio links for packet??? If so
>can you spare any information on your setup. Or at least point me in the
>right direction for getting some info please. e.g. what hardware are you
>using for the radio side? What gear are you using from the computer to radio.
I don't have such a link running get, but I do have one "under
construction." I'm following the analog design given by n6gn in the ARRL
Handbook, but I plan to replace his ECL interface with a syncronous T1-rate
interface. Our PackeTens here will take the RS422 directly; PCs will
require a DMA board like the PackeTwin or PI board.
So far, I have the microwave transceivers, modulators, and 1st IF strips
working. Now that I have 2nd IF and receiver board artwork from ke3z, the
rest of the analog work shouldn't be too hard. This artwork and other
construction notes should be available from n6gn via anonymous ftp soon.
Watch this space for more details.
73, Bob, ke9yq
------------------------------
Date: Tue, 1 Jun 1993 0:43:59 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: TCP Blimit
To: nos-bbs@hydra.carleton.CA, tcp-group@ucsd.edu
I wrote the "tcp blimit" (later the "tcp bblimit") code. This is a backoff
clamp. In effect, what this says is that the TCP timers will reach a point
where they do not increase the interval between retries. This is a network
wide parameter, and it makes no real difference if your particular frequency
is busy or not.
NOS gives two choices for "tcp timertype": "exponential" and "linear". In
the case of the exponential timer, the measured rtt (sort of) is shifted
by the backoff counter as an index. Since this number is stored in a long
integer, allowing more than 31 shifts would produce a carry and a zero
result for the timer, which would be clearly disastrous. You simply can't
back off the exponential timer more than 31 times.
In the case of the linear timer, the blimit/bblimit has a different function.
The measured rtt is multiplied by the backoff counter, so the possibility of
an overflow is essentially nonexistent. However, experience has shown that
the backoff counter usually reaches high values (more than 20 or so) because
the target host is not on the air. Since it is expected that the target
host will eventually turn up on the air again, it is desirable to retry the
frame once every hour or two instead of allowing the backoff to reach days
between retries.
There are other implementations of the backoff limit using different types
of algorithms. KA1JY did a fairly interesting one tied to the exponential
algorithm, and his was also named "tcp blimit". I renamed mine to "tcp
bblimit" in order to distinguigh mine from his. (His was first, by the way.)
Note that these issues have been controversial. It is a significant issue
as to whether the use of linear backoff is appropriate. It is also an issue
as to whether any backoff clamp is legitimate. In the case of JNOS, which
times out TCP circuits, this is even more complicated.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: Mon, 31 May 1993 19:08:08 -0400
From: ashok@biochemistry.BIOC.CWRU.Edu (Ashok Aiyar)
To: tcp-group@ucsd.edu
At 03:53 PM 5/30/93 -0700, Phil Karn wrote:
>What's wrong with just accepting the RCPT TO: command? Be conservative
>in what you send, be liberal in what you accept...
Yes, you are correct. I changed it to accept both RCPT and MAIL commands
in any order, but DATA only after both MAIL and RCPT.
Someone else mentioned that several MTAs have problem with the Microsoft
SMTP gateway for this precise reason, i.e it is very rigid about the
order in which commands are received in that MAIL FROM: must precede
RCPT TO:
Thanks,
Ashok
--
Ashok Aiyar Mail: ashok@biochemistry.cwru.edu
Department of Biochemistry Tel: (216) 368-3300
CWRU School of Medicine, Cleveland, Ohio Fax: (216) 368-4544
------------------------------
End of TCP-Group Digest V93 #141
******************************
******************************