Date: Fri, 31 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 #339
To: tcp-group-digest
TCP-Group Digest Fri, 31 Dec 93 Volume 93 : Issue 339
Today's Topics:
Ohio TCP/IP address updates
ucsd.edu : swamik@ele.uri.edu
What does this mean?
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, 30 Dec 93 10:33:28 EST
From: samalott@sampc.cmhnet.org (Stephen A. Malott)
Subject: Ohio TCP/IP address updates
To: n8fow@wsu.n8fow.ampr.org_tcp-group@ucsd.edu
I have e-mailed you a copy of N8EMR's latest (12/25/93) Ohio IP address list.
Gary's email addresses appear at the top, but here they are for any other
interested parties:
Gary W. Sanders Internet: gws@n8emr.cmhnet.org
Packet: n8emr@n8jyv.#cmh.oh.usa.na
Hope this helps you!
================================================================ Stephen A. 'SAM' Malott Packet: N8JYV@N8JYV.#CMH.OH.USA.NA Internet: samalott@sampc.cmhnet.org
------------------------------
Date: Thu, 30 Dec 1993 22:50:55 +0100 (MET)
From: pe1kda%pe1kda@pi8yrc.ampr.org
Subject: ucsd.edu : swamik@ele.uri.edu
To: tcp-group@pa2aga.igg.tno.nl
Date: Thu, 30 Dec 93 22:30:14 GMT
Message-Id: <3@pe1kda.ampr.org>
From: jelle@pe1kda.ampr.org (Jelle Aardema)
Reply-To: pe1kda@pe1kda
To: tcp-group@pa2aga
Subject: swamik@ele.uri.edu
X-Mailer: pc-mos/386 mailer testrel 1.75 (c) 1990 pe1jlj
X-O/S: ms-dos
To : swamik@ele.uri.edu
>From : jelle@pe1kda.ampr.org
Shwamik,
Have a look at this TCP-Group Digest mail. I used this information myself
to obtain the source files needed for putting the Sun IPX to AX25, by use of
a KISS configured TNC on one of the serial ports.
Source code is available on UCSD.EDU by FTP, in compressed form: fully docu-
mented and well described in 'where to modify what?'.
Please let me know if the software is unreachable: I still have it on floppy.
----------------- 8<--- 8<--- cut here 8<--- 8<--- -----------------------
TCP-Group Digest Wed, 22 Sep 93 Volume 93 : Issue 245
Today's Topics:
KA9Q base code and scrollback
SunOS 4.X AX25 kernel driver
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: Wed, 22 Sep 93 07:31:45 UTC
From: wj8q@wsu.n8fow.ampr.org
Subject: KA9Q base code and scrollback
To: tcp-group@ucsd.edu
Hiya..
Just a note- I'm the one that had the problem. I have since figured out
what it was. I'm not sure if it was intended to work this way or not, but
what happens is that it won't open the TMP files into any TMP environment
setting set to a root directory of a drive. I had my TMP environment
set to a ramdrive, d:\, and it wouldn't do any temp file opening.
Same on testing using main drives, etc-But I kept setting to root and
it didn't help--
Once I made a directory in the ramdrive + set my TMP environment to that
drive+directory, no problem.
Thought I'd let y'all know.
73's,
Wes
_______
SMTP/Internet: wj8q@hamgate.cc.wayne.edu
LAN: wj8q@wsu.n8fow.ampr.org
: Wj8q@wj8q.ampr.org : 44.102.40.18
------------------------------
Date: Wed, 22 Sep 1993 01:02:01 -0700 (PDT)
From: William.Dorsey@Corp.Sun.COM (Bill Dorsey)
Subject: SunOS 4.X AX25 kernel driver
To: tcp-group@ucsd.edu
Hi,
Earlier, I asked a question about setting netmasks and broadcast addresses,
and setting up routing on a Sparcstation running SunOS 4.X and the AX25
kernel driver in the /hamradio/packet/sun directory on ucsd.edu. I was
able to establish outgoing connections from my machine to other hosts on
amprnet, but they were not able to establish connections with me. I was
led to believe this was because I didn't have routing set up correctly,
or perhaps because I was using the wrong netmasks.
After having spent many hours pulling my hair out trying to figure out
what was going on, I finally bit the bullet and began sprinkling some
printf's in the AX25 driver to see what was going on. After a few more
hours of debugging, I realized that incoming ARP requests weren't being
answered. As you can see below from the context diffs between the orig-
inal tty_ax.c and my tty_ax.c, this is because the network interface
ethernet address was being compared against the ax25 broadcast address
in code which determines whether or not a packet is destined for our
host. This is incorrect, and should be a comparison between the incoming
ethernet address and the ethernet broadcast address.
The original code would never pass ARP requests (which have their ethernet
destinations set to be the ethernet broadcast address) to our host to the
kernel, and thus the kernel would never generate an ARP reply. This
prevents other stations from establishing a connection to the Sun, and
thus severely limits the utility of the driver.
I hope this is useful to someone... The full source code to the driver is
available for anonymous ftp from n3lmf.ampr.org. The connection is very
slow and the w6yx gateway seems to be down a lot, so if there is much
demand, I can put it on ucsd.edu.
*** tty_ax.c.old Fri Sep 3 14:24:18 1993
--- tty_ax.c Tue Sep 21 19:46:30 1993
***************
*** 472,478 ****
ax_ax2ether(ax->ah_dst, &oureth);
if( bcmp((caddr_t)&oureth, (caddr_t)&axp->arpcom.ac_enaddr,
sizeof oureth) &&
! bcmp((caddr_t)ax25broadcastaddr, (caddr_t)&a->arpcom.ac_enaddr,
sizeof oureth)) {
*forusp = 0;
}
--- 472,478 ----
ax_ax2ether(ax->ah_dst, &oureth);
if( bcmp((caddr_t)&oureth, (caddr_t)&axp->arpcom.ac_enadd
sizeof oureth) &&
! bcmp((caddr_t)&oureth, (caddr_t)ðerbroadcastaddr,
sizeof oureth)) {
*forusp = 0;
}
--
Bill Dorsey william.dorsey@corp.sun.com
PGP 2.X public key n3lmf@n0ary.#norcal.ca.us.na
available on request dorsey@n3lmf.ampr.org
------------------------------
End of TCP-Group Digest V93 #245
******************************
----------------- 8<--- 8<--- cut here 8<--- 8<--- -----------------------
Jelle Aardema : PE1KDA @ PI8NVP.NH.NLD.EUR : AX25 BBS
pe1kda @ pe1kda.ampr.org : ampr Internet [44.137.36.55}
aardemaj @ ges.getronics.nl
----------------- 8<--- 8<--- cut here 8<--- 8<--- -----------------------
------------------------------
Date: Thu, 30 Dec 1993 18:37:26 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: What does this mean?
To: kf5mg@kf5mg.ampr.org
Assuming that the system returning you those source quenches is running
something close to my original NOS code, the most likely reason you're
getting them is because k5vr's system is not on the air.
NOS can return source quenches for several different reasons, but the
most common in AX.25 operation is an unresolved ARP. When a NOS system
with an AX.25 interface tries to send or forward a packet to an IP
address that's not in the ARP cache, ARP saves the packet and
broadcasts an ARP request instead. It holds onto the original packet
for something like 15 seconds, pending a response. If the ARP response
comes back in that time, the original packet is then forwarded
normally. If the ARP doesn't come back in 15 seconds, the original
packet is silently discarded (a purist would argue that it should be
bounced with a destination unreachable, but this still breaks too many
TCPs).
Now if additional packets arrive for a target that's still pending ARP
resolution, they are immediately returned with a source quench; you
can only have one outstanding packet on the queue at a time. And if
the target station isn't on the air, the ARP will never be resolved.
And if you try to send more than one packet to such a station every
15 seconds, you'll see the source quenches.
So the bottom line is this: repeated source quenches from a gateway
transmitting on an AX.25 channel are a very good indication that the
next station on the path is down or unreachable and has been so for
more than 15 minutes (the ARP cache timeout).
Phil
------------------------------
End of TCP-Group Digest V93 #339
******************************
******************************