Date: Fri, 7 Jan 94 04:30:01 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 V94 #3
To: tcp-group-digest
TCP-Group Digest Fri, 7 Jan 94 Volume 94 : Issue 3
Today's Topics:
AMPR.org Domain
Extended KISS and SMACK specifications? (4 msgs)
JNOS and Turbo C++ 3.0
Problem compiling KA9Q nos..
test
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: Thu, 6 Jan 1994 11:10:56 -0600 (CST)
From: ssampson@sabea-oc.af.mil (Steve Sampson)
Subject: AMPR.org Domain
To: tcp-group@ucsd.edu
Over the holidays I made a few additions to the domain and
then downloaded the file to see how all my entries took.
While my changes took as desired, I was surprised by the
number of errors in there! Rather than search for them
all, I just changes the obvious errors. The most
significant number of errors was leaving the ',' off the
end of a non-ampr.org domain. Some people used ampr.org
in their entry and never used a '.' and thus were known
as:
jimbob.ampr.org.ampr.org
after "ampr.org" is added to everything without a dot.
Most cases were in the MX record though, and by leaving
a '.' off the end of a "fully qualified domain name"
results in:
jimbob-state.edu.ampr.org
Not really what you wanted is it...
Anyway, you might take a look at the result and see if
yours is fixed now :-)
--
Steve
------------------------------
Date: Thu, 6 Jan 1994 14:38:11 +0200 (EET)
From: mea@mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
Subject: Extended KISS and SMACK specifications?
To: louie@uunet.uu.net (Louis A. Mamakos)
> > My PK-88 supports "Extended KISS". This appears to include checksums,
> > reporting of the transmission of a packet, and polling of the TNC by the
> > host.
>
> Wow. Is this all a good thing?
>
> KISS = "Keep It Simple, Stupid"
Yes. Lack of checksums on KISS in between TNC and the computer
has been shown to be a problem on some cases (loaded computer,
multiple TNCs, ..) While it improves the interface in between
the TNC, and the computer, it still is very KISS in deed.
Alternative would be to hack automatic interaction with various
types of TNCs -- and running TCP/IP would be next to impossible..
I think Phil Karn had something to do with that E-KISS protocol,
or was it just that he has said what things are missing missing from
the original specs ?
> louie
> wa3ymh
/Matti Aarnio <mea@utu.fi> oh1mqk
------------------------------
Date: Thu, 6 Jan 1994 09:57:47 -0800 (PST)
From: Lyndon Nerenberg <lyndon@unbc.edu>
Subject: Extended KISS and SMACK specifications?
To: "Louis A. Mamakos" <louie@uunet.uu.net>
On Wed, 5 Jan 1994, Louis A. Mamakos wrote:
> > My PK-88 supports "Extended KISS". This appears to include checksums,
> > reporting of the transmission of a packet, and polling of the TNC by the
> > host.
> Wow. Is this all a good thing?
Yes. There is no excuse for not having a data integrety check between the
TNC and computer, especially in light of the (IBM) PC's ability to drop
characters.
I'm not sure what's meant by "polling" here, however something else
that's sorely needed is the ability for the TNC to notify the PC that a
packet has been sent over the air. This let's the PC start the retransmit
timer when the packet is sent on the air, rather than when the PC sends
to the TNC.
> KISS = "Keep It Simple, Stupid"
You want to keep the protocol broken just to maintain backwards
compatibility with the name? Foo!
--lyndon
------------------------------
Date: Thu, 06 Jan 1994 17:32:04 -0500
From: "Louis A. Mamakos" <louie@uunet.uu.net>
Subject: Extended KISS and SMACK specifications?
To: Lyndon Nerenberg <lyndon@unbc.edu>
[I wrote..] > > Wow. Is this all a good thing?
> Yes. There is no excuse for not having a data integrety check between the
> TNC and computer, especially in light of the (IBM) PC's ability to drop
> characters.
Sure, there's a great excuse. KISS was supposed to be SIMPLE and EASY
to implement on hardware that couldn't support a direct connection to
the link-layer hardware.
> I'm not sure what's meant by "polling" here, however something else
> that's sorely needed is the ability for the TNC to notify the PC that a
> packet has been sent over the air. This let's the PC start the retransmit
> timer when the packet is sent on the air, rather than when the PC sends
> to the TNC.
Once you begin to add all this complexity, I contend that you'd be
better off spending the effort writing a driver to support a more
tightly-coupled hardware interface.
> > KISS = "Keep It Simple, Stupid"
>
> You want to keep the protocol broken just to maintain backwards
> compatibility with the name? Foo!
No, the point as I understand it was to build a simple, non-broken,
low-capability protocol. I claim that attempting to unreasonably
extend the KISS protocol breaks it.
louie
wa3ymh
------------------------------
Date: Thu, 6 Jan 1994 14:59:05 -0800 (PST)
From: Lyndon Nerenberg <lyndon@unbc.edu>
Subject: Extended KISS and SMACK specifications?
To: "Louis A. Mamakos" <louie@uunet.uu.net>
> > Yes. There is no excuse for not having a data integrety check between the
> > TNC and computer, especially in light of the (IBM) PC's ability to drop
> > characters.
> Sure, there's a great excuse. KISS was supposed to be SIMPLE and EASY
> to implement on hardware that couldn't support a direct connection to
> the link-layer hardware.
Do you work for Sun? This sounds like their reasoning for turning off NFS
UDP checksums: dump the error checking so we can make the benchmarks look
better.
KISS = Keep It Stupid, Simple.
Not!
------------------------------
Date: Thu, 06 Jan 94 15:47:00 PST
From: Martin Lines <mlines@sni.co.uk>
Subject: JNOS and Turbo C++ 3.0
To: "'nos-bbs'" <nos-bbs@hydra.carleton.ca>, tcp-group <tcp-group@ucsd.edu>
Has anyone achieved the impossible and got a vaguely stable version of JNOS
using the TC++ 3.0 compiler.
Mine crashes instantly with Invalid pointers in cmdintr.
Here' s hoping!
Martin - G1SEO
------------------------------
Date: Thu, 06 Jan 94 10:14:15 EST
From: RLM@MAINE.maine.edu (Robert L. Metcalf NV1A)
Subject: Problem compiling KA9Q nos..
To: tcp-group@ucsd.edu (TCP folx)
Hi..
I have a question about NOS... I FTP'd what I think is the latest
version of KA9Q NOS from ucsd.edu:
-r--r--r-- 1 257 939922 Jul 1 1993 rcsdsrc.zip
I have un-RCS'd the files and compiled and assembled all
of the pieces (with make), but make has a problem when it
comes time to link everything together. There are a
lot of undefined labels, etc.. I think my problem is that I am using
Turbo C++ version 3.0 and an old version of TASM (v1.01).. I think the
.OBJ files created by my TASM are not compatible with the new compiler
tools.(?) Is there a way to fix this?
Are the .OBJ files for the new assembly source available via FTP?
Thanks!
Rob NV1A
rlm@maine.maine.edu
------------------------------
Date: Thu, 06 Jan 94 13:03:00 PST
From: tijc02!SMROUTER!LEROJX%ALPH1%SIAMAIL%MSROUTER@uunet.UU.NET
Subject: test
To: tcp-group@ucsd.edu
TO:smrouter/tcp-group@ucsd.edu
test
------------------------------
End of TCP-Group Digest V94 #3
******************************
******************************