Date: Wed, 17 Feb 93 04:30:09 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 #45
To: tcp-group-digest
TCP-Group Digest Wed, 17 Feb 93 Volume 93 : Issue 45
Today's Topics:
3c509 packet driver release 10.1
Anyone got a vanilla copy of grinos 2.0J source?
Death of AX.25 (2 msgs)
Mystery NIC
NOS & MSC under Windows NT?
NOS book TOC
Please unsubscribe
redoing amateur packet
Slip package ?
Stat
Uncle! UNCLE! (Problem with FTP on NET)
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, FEB 16 1993 08:48:56
From: Carlton Ellis <CELLIS%BROCK1P.bitnet@CUNYVM.CUNY.EDU>
Subject:
To: <tcp-group@ucsd.edu>
subscribe Carty Ellis KA2Y
------------------------------
Date: Tue, 16 Feb 93 17:40:05 GMT
From: nelson@crynwr.com (Russell Nelson)
Subject: 3c509 packet driver release 10.1
To: drivers@sun.soe.clarkson.edu
The 3c509 packet driver has been officially released at version 10.1.
All the beta test copies have been 10.0, so if you have one, please
upgrade to 10.1. The driver is in 3c509a.zip and is (will be) on all
your favorite FTP/UUCP/BBS sites:
Please report problems. I cannot guarantee that I will work on your
problem if you are not a Crynwr customer. I CAN guarantee that I
will not work on it if you don't report it to me. Written reports
are preferred to phone calls.
-- HOWTOGET.IT
The Crynwr packet driver collection
Availability
The Crynwr packet driver collection is available by mail, by FTP, by
email, by UUCP and by modem. The drivers are distributed in three files:
drivers.zip, which contains executables and documentation,
drivers1.zip, which contains the first half of the .ASM files, and
drivers2.zip, which contains the second half of the .ASM files.
Mail:
Columbia University distributes packet drivers by mail. The formats
are 9-track 1600 bpi tapes in ANSI, tar, or OS SL format, or PC
diskettes (360K 5.25" and 720K 3.5"). The exact terms and conditions
have yet to be worked out, please call (212) 854-3703 for ordering
information, or write to:
Kermit Distribution, Dept PD
Columbia University Center for Computing Activities
612 West 115th Street
New York, NY 10025
or send e-mail to kermit@watsun.cc.columbia.edu (Internet) or
KERMIT@CUVMA (BITNET/EARN).
FTP/email:
The packet driver collection has its own directory devoted to it on
simtel20.army.mil, pd1:<msdos.pktdrvr>. The drivers are there, along
with many free programs that use the packet drivers.
SIMTEL20 files are also available by anonymous ftp from mirror sites
OAK.Oakland.Edu (141.210.10.117), wuarchive.wustl.edu (128.252.135.4),
ftp.uu.net (137.39.1.9), nic.funet.fi (128.214.6.100), src.doc.ic.ac.uk
(146.169.3.7), nic.switch.ch (130.59.1.40), archie.au (139.130.4.6),
nctuccca.edu.tw (140.111.3.21), by e-mail through the BITNET/EARN file
servers.
Modem:
If you cannot access them via FTP or e-mail, most SIMTEL20 MSDOS
files, including the PC-Blue collection, are also available for
downloading from Detroit Download Central (313) 885-3956. DDC
has multiple lines which support 300/1200/2400/9600/14400 bps
(103/212/V22bis/HST/V32bis/V42bis/MNP). This is a subscription system
with an average hourly cost of 17 cents. It is also accessable on
Telenet via PC Pursuit and on Tymnet via StarLink outdial. New files
uploaded to SIMTEL20 are usually available on DDC within 24 hours.
CD-ROM:
Public, private or corporate institutions and libraries interested in
the SIMTEL20 MS-DOS collection in CD-ROM format bundled with library
card-catalog type access and duplication software can contact Coyote
Data, Ltd. by mail at 1142 N. Main, Rochester, MI 48307 or by FAX at
(313) 651-4071. Others who do not need the access and duplication
software should send e-mail to: rab@cdrom.com (Robert Bruce), telephone
(800) 786-9907 or (510) 947-5996, or FAX (510) 947-1644 for details on
his CD-ROM offer.
UUCP:
The packet driver files are available from UUNET's 1-900-GOT-SRCS, in
uunet!~/systems/msdos/simtel20/pktdrvr. Contact UUNET for more details:
UUNET Technologies, Inc.
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 204 8000 (voice)
+1 703 204 8001 (fax)
info@uunet.uu.net
-- end of HOWTOGET.IT
-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software Crynwr Software sells packet driver support.
11 Grant St. 315-268-1925 Voice | LPF member - ask me about
Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do.
------------------------------
Date: Tue, 16 Feb 1993 22:44:31 +0000 (GMT)
From: root@thed.uk22.bull.com (0000-Admin(0000))
Subject: Anyone got a vanilla copy of grinos 2.0J source?
To: tcp-group@ucsd.edu
Hi all,
I'm looking for a vanilla copy of the PA0GRI nos 2.0J source code
to replace the one I have lost. Can anyone help? It MUST be the J version
as I need it to run 'diff' against it, so that I can sort out some changes
of my own.
73 all,
Kelvin. (G1EMM)
------------------------------
Date: Tue, 16 Feb 1993 12:10:09 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Death of AX.25
To: tcp-group@ucsd.edu
> Anyway, "accepted protocol" is a lot less restrictive than "AX.25"
> (accepted by whom, the user?)
Why not just allow 'digital communications' of any form? For example, the
Canadian regulations only specify bandwidth restrictions (different for each
band). Within these restrictions, you can use any analog or digital mode you
want. Make it alot easier to experiment, which is one of the purposes of
Amateur Radio...
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Tue, 16 Feb 93 10:09:12 PST
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: Death of AX.25
To: tcp-group@ucsd.edu
OK guys (and gals). Before we get too carried away designing the "perfect"
link layer, can we at least decide what the attributes are? AND, show where
and why AX.25L2 fails these? Everyone seems to have different ideas on what
these attributes are, so why not enumerate them for all to see?
As an example, one of the gripes I have seen about AX.25 is that it does not
provide adequate congestion control. It provides very poor congestion control
on simplex links, where some other link control method may be much better (say
token passing or centralized control node, both of which also have major
problems). However, when with a full-duplex "digipeater", congestion
control
is quite good. This is a very large reason that most commercial data systems
run split-frequency t/r. The point here is that some of the problems may be
best handled somewhere else besides the link layer.
If we indeed do propose to change the link layer, then we should lay all
technologies on the table, including the newer frame link techniques. Note
that
I am not declaring pro or con on AX.25L2. It's biggest advantage is that
virtually all ham TNCs have it implemented. But oh those little 256 byte
frames...
So, shall we define the problem before we provide a solution?
Jack Brindle
------------------------------------------------------------------------------
ham radio: wa4fib internet: jackb@mdd.comm.mot.com
------------------------------
Date: Tue, 16 Feb 93 22:44:05 MET
From: pa0gri@tophat.cdh.cdc.com
Subject: Mystery NIC
To: ORV%wpgate@micom.micom.com (ORVILLE BEACH)
Helo Orv,
> Can someone help me identify a 3COM NIC? It's an 8-bit card,
> with BNC and AUI connectors. The assembly part no. is 1221 00
> Rev. G. It has space for a boot PROM marked U10.
>
> If there are any unique arrangments of parts that can help
> identify the model no. of this card, I can supply that info.
>
According to my book the 1221 is a 3c501 type (like the 0345 and 34-0780)
It is a 3/4 size card and has the same 1 frame limit as the other (old/long)
3c501.
The mdel 1194 and 2012 are 3c505 types....
> Thanks in advance.
>
> orv - wb6wey -
>
> orvb@micom.com
>
Regards, Gerard.
------------------------------
Date: Tue, 16 Feb 93 17:58:32 CST
From: jimh%kd4ldo.tcman.ampr.org@skeggi.vware.mn.org
Subject: NOS & MSC under Windows NT?
To: tcp-group@ucsd.edu
Walt (and others):
Porting the OS/2 app may not be the most straight forward for me; I'm used to
DOS apps (and UNIX, to an extent), and am also one of the strange people who
prefer a CL interface as opposed to a GUI. But that is a thought; in fact, I
have considered getting a hold of the Windows NT DDK and writing an AX.25 w/
TCP/IP encap driver to use with NOS; then I would be able to use all of the
native utilities that come with NT.
Of course, I have *no* idea how to write a device driver... :-)
----
Jim Henderson, KD4LDO/W0 jimh@kd4ldo.ampr.org [44.94.249.38] on 144.99 MHz
Crystal, MN Internet: jimh%kd4ldo@skeggi.vware.mn.org
CIS: 71321,1461 Alt. Internet: hendersj@alpha.db.erau.edu
"Don't ask me how it works or I'll start to whimper!" - Arthur Dent
------------------------------
Date: Tue, 16 Feb 1993 20:43:01 -0600 (CST)
From: Mr. Steve Sampson NSA/OK <ssampson@sabea-oc.af.mil>
Subject: NOS book TOC
To: TCP-Group@UCSD.Edu
Jim Chesner, N9GBH 70040.125@compuserve.com writes:
"NOSintro - TCP/IP over Packet Radio".
Its contents are as follows:
1 - Intro to NOSintro 18 - NOS BBS-The Big Picture
2 - NOSview 19 - Setting up the NOS BBS
3 - The Ground Rules 20 - The NOS BBS Command Set
4 - NOS in a Nutshell 21 - Hands On-BBS File Server
5 - Let's Meet the Locals 22 - Hands On-Remote Sysop
6 - The TNC Revisited 23 - Forwarding SMTP Mail
7 - A Peek at Protocols 24 - Pop Mail Collection
8 - Names, Domains and Addresses 25 - PBBS Mail Forwarding
9 - Client/Server 26 - AX.25 Routing
10 - Hands On-Hardware Checkout 27 - Address Resolution Protocol
11 - Hands On-Software Installation 28 - IP Routing
12 - NOS File Compendium 29 - NET/ROM Routing
13 - Hands On-Session Manager 30 - Going Live:Preparing the Files
14 - The NOS Command Set 31 - Hands On-AX.25
15 - Hands On-autoexec.nos 32 - Hands On-NET/ROM
16 - The ftpusers File 33 - Hands On-Ping and Hop
17 - Hands On-FTP 34 - Hands On-DNS System
35 - Trailing Flag
APPENDICES
1 Where to get the Software
2 NOS Command Set Reference
3 NOS Control Files
4 Character Codes
5 IP Address Coordinators
6 References
- 356 pages, copiously illustrated with over 80 detailed diagrams, plus
countless examples of commands and screen displays.
- Full listings of all the control files needed for NOS.
---
Just thought others would be interested in a T.O.C. description. Funny the
things you find on compuserve that really should have been here first...
Steve, N5OWK
------------------------------
Date: Wed, 17 Feb 93 13:53:19 WET
From: chermesh@bgumail.bgu.ac.il (Ran Chermesh)
Subject: Please unsubscribe
To: TCP-Group@ucsd.edu
Hi,
Please do me a favor and unsubscribe me from the tcp-group list.
I tried a few times to unsubscribe, but all I get is that I'm NOT on the
list.
--
Ran Chermesh E - M A I L
Behavioral Sciences Dept. ===========
Ben-Gurion University Internet: CHERMESH@BGUVM.BGU.AC.IL
Beer-Sheva 84105 CHERMESH@BGUMAIL.BGU.AC.IL
Israel Bitnet : CHERMESH@BGUVM.BITNET
Phone: 972-57-472-057 Fax: 972-57-232-766
------------------------------
Date: Tue, 16 Feb 93 9:00:35 PST
From: Glenn Elmore <glenne@srlr12.sr.hp.com>
Subject: redoing amateur packet
To: tcp-group@ucsd.edu
Phil wrote:
> At 10:37 2/9/93 -0800, Jeffrey D. Angus wrote:
>
> >KISS Mode? The only things that would have to stay constant while re-using
> >existing TNCs are the BELL-202 modem and the 8530 HDLC.
>
> Actually, if you really want to redo amateur packet radio right from
> the ground up, even these have to go. I'm becoming convinced that some
> form of forward error correction (FEC) is essential, at least as an
> option when links get bad, and this pretty much precludes HDLC framing.
I see your SCC, TNC, FEC and I raise you an engineered physical layer.
(:>)
I agree that existing hardware doesn't cut it and that FEC and power
control are useful. However, these seem to me to be bandaids on a bad
situation or, at best, a form of adaptation necessary because the lower
layer hasn't been more effectively utilized.
We (hopefully) turn on power control when the available radio
capacity is greater than that which is necessary for maximum desirable
throughput and we turn on FEC when something has happened such that
"full" throughput is no longer possible under the circumstances. Both
of these adaptations come about because we are trying to operate in a
system which has extreme variations. I believe that if we are to redo
amateur packet we simply can not afford to ignore the system engineering
as we have so far. We must design our physical links more carefully.
If all paths were fully line-of-sight with sufficient margin and short
enough, near freespace conditions might prevail and power could be
properly set(at a very low level indeed) and left and error correction
would never be necessary. Of course this begins to sound as likely as
having the national deficit eliminated and I have similar hope of seeing
each.
Amateur reality is not likely to be able to produce and support the
above conditions for many users in the near future. However, I think we
need to look carefully at the costs and returns of the bigger picture
before we only apply bandaids.
Many of the problems we are having come about because radio is not as
well controlled and as reliable as the wireline environment from which
our previous experience and available tools and techniques come. But
it's not just for the applicability of available technology that we
should try to engineer our links to provide higher quality more
uniformity. The benefits in terms of user-throughput/user-$ are heavily
weighed in the favor of having quality paths whenever and wherever
possible.
Put more succinctly, if we are to redo amateur packet in order to
have an effective wide area amateur radio digital network we are going
to have to get the "radio" part a lot more right.
We are going to have make a concerted effort to build links,
particularly backbones which have high information content, which
operate over carefully selected paths and provide reliable and stable
information transport. The approach of just putting up an antenna and
slugging it out with amateur machismo, even with useful techniques like
FEC and power control to help, won't do it. I'm convinced that the
return on investment in quality paths is *much* greater than that of the
best adaptive techniques to deal with the problems and losses incurred
by poor ones.
For user access we are certainly going to find things less than ideal.
The mobile (as with four wheels) environment is a particularly big
headache and requires special consideration. But if we don't begin to
get good at adding radio hops and picking good intermediate sites for
home qth and backbones the best of adaptive techniques is not going to
produce a network for us. I think we have to better collaborate locally
to build shared systems and improving paths. Inexpensive hardware added
in the right places can be orders of magnitude more effective than
"corrective" techniques to make up for bad/variable paths.
> The reason FEC precludes HDLC framing is because you need a much more
> robust synchronizing sequence to start off each frame. An HDLC flag is
> much too short. You need something more like 32 or 64 bits long that
> can be recognized reliably by a correlator even when a substantial
> fraction (say 10%) of the bits are in error.
>
> The Bell-202 modem I won't even talk about.
(it probably wouldn't make it through the obscenity filters anyway. (:>) )
In the next phase of 1200 MHz SS user radios I'm trying to run
everything fully synchronous. Carrier frequency, chipping rate, data
clocks and pilot tones are all synchronous and modulation/demod is
coherent. This way, all energy transmitted can go to synchronization as
well as to data. In addition, I'm hoping to maintain synch even while
the hub is polling other users within the Hubmaster cluster. Synch can
have the length of the PN sequence itself and can be remembered.
Lest I leave the wrong impression, I agree with the value of FEC and
power control and I'm also including hooks for both in the next radios.
Since I know that I can't foresee what techniques will be optimum, both
I and Q channel inputs and outputs remain accessible providing
completely general channel access so that DSP or other techniques can be
built to optimize performance.
If there is an FEC expert out there who wants to apply his craft to
amateur radio let me know, it certainly isn't me and I'm going to need
help.
73
Glenn Elmore n6gn
------------------------------
Date: Tue, 16 Feb 1993 18:14:34 +0000 (MET)
From: Eigil Krogh Sorensen <eks@vki68.aar-vki.dk>
Subject: Slip package ?
To: tcp-group@ucsd.edu
Do you know if there is a SLIP (Serial Line IP) package that can be
used on Motorola sysV/68 R3V6 that has Network Services Extensions
(NSE) installed ?
Thank you in advance.
Eigil Krogh Sorensen
(eks@aar-vki.dk)
------------------------------
Date: Tue, 16 Feb 1993 11:00:58 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Stat
To: kz1f@legent.com
On Fri, 12 Feb 1993 kz1f@RELAY.WESTBORO.LEGENT.COM wrote:
> Posix, find me a posix compliant compiler for DOS/WINDOWS/OS2
Please get this straight so that we can go on talking about
networking. ANSI did not standardize ANY system calls. IF YOU READ A
DIRECTORY, IT ISN'T PURE ANSI C, since ANSI didn't provide any portable
directory-reading facilities. So stop reading directories if you
insist on writing programs to the pure ANSI standard. If you really
want to read directories, your best bet is to use the POSIX-compliant
facilities that came with your compiler. These facilities come with
Microsoft C, Zortech, and Watcom, and Borland is catching up. NOS
is already written to use them, since it is based on a predecessor
to POSIX.
Now, let's get back to talking about networking instead of worring
about whether stat() is suddenly going to disappear from all of the
world's C libraries!
Bruce Perens
------------------------------
Date: Tue, 16 Feb 93 11:19 CST
From: prg@mgweed.att.com
Subject: Uncle! UNCLE! (Problem with FTP on NET)
To: TCP-Group@UCSD.Edu
Well, I just have to scream "UNCLE" on this one, I'm at the end of my rope
and hope someone can at least steer me in the right direction -- oh, and
my apologies if this is not the correct forum..
I'll try to state the symptoms quickly and ask "What am I missing?"
I'm running the K5JB NET software on a 3B2/310, SysV 3.2.2, and it works
quite well, other than ftp'ing to places that are very far away! I can
ftp to local stations, I can ftp to "ham" stations 4 and 5 hops away from
me ALWAYS. As soon as I try to hit the interenet, I get absolutely no
response to my ftp request. Are you ready for this, I can ping the remote
location and get a response within 2-3 seconds over and over again, but the
ftp request (and here's another clinker) except on two occasion over several
months (!) goes totally ignored. Try ping'ing again, no problem. I've
tried "ftp 128.54.16.1" (and yes, the proper port [21] is attached to the
ax25 protocol when it goes out), no response.
I tried changing my default routing station to another friends station and
watched the packets (via hex trace) leave me, go to him, leave him and go
to his default router -- nothing comes back to me. I ping through him
to, say 128.54.16.1, and right back it comes!
I had another friend who uses the same default router I do, record the
hex dump of my request followed immediately by a request from him. His
of course connected, mine didn't. In comparing the two hex dumps, the only
thing different of consequence I could see, is that the "C" bit in the
ax25 protocol was missing from my transmission but was in his. I was
assured that this would not cause my problem. We even put his callsign
on my machine, along with his net address, making my machine look, for
all practical purposes, like it was him transmitting through the router,
it still doesn't work.
I've done everything I can think of, even played around with how the
checksums are calculated and can't fix my problem. I've put print statements
all over in the code, but it's a little hard to try to solve the problem
when I don't see what the problem is!
I'll attach the hex dump of my one packet and then I'll go away. If anyone
can help, off-line, or what ever, I'll be eternally greatful!
========================================================================
net> ftp 128.54.16.1
SYN sent
len = 24 sum = fb29 <-- TCP checksum
len = 20 sum = ae4b
len = 20 sum = 0000
len = 20 sum = af4b <-- IP checksum
ax0 sent:
AX25: WA9DNZ->N4PCR-1 UI pid=IP
IP: len 44 44.72.41.2->128.54.16.1 ihl 20 ttl 38 prot TCP
TCP: 1001->21 Seq x1a919af0 SYN Wnd 472 MSS 472
0000 9c 68 a0 86 a4 40 62 ae 82 72 88 9c b4 61 03 cc .h .$@b..r..4a.L
0010 45 00 00 2c 00 00 00 00 26 06 af 4b 2c 48 29 02 E..,....&./K,H).
0020 80 36 10 01 03 e9 00 15 1a 91 9a f0 00 00 00 00 .6...i.....p....
0030 60 02 01 d8 fb 29 00 00 02 04 01 d8 `..X{).....X
========================================================================
As I said before, I went through every structure that creates this, and
all I saw that seemed strange was in byte 0006, the "62" seemed as though
it maybe should have had its most significant bit set and been "e2".
Thanks for any help..
Phil Gunsul - WA9DNZ/WB9AAX - 44.72.41.2
------------------------------
Date: Tue, 16 Feb 93 10:23:22 MST
From: LARSEN Karl <klarsen@mercury.arl.army.mil>
Need help with POP3. I'm set up as the server and have watched
several connects from users. The exchange seems to go well and if the
mail is small < 5 kbyte the user gets his mail. If the mail waiting
is > 5kb the echange looks good, but then nothing happens for awhile
and then my nos fails!
Has anyone had similar luck, and am I lucky to get some info?
73, karl k5di@k5di.nm.usa.na
------------------------------
End of TCP-Group Digest V93 #45
******************************
******************************