Date: Mon, 10 May 93 04:30:11 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 #120
To: tcp-group-digest
TCP-Group Digest Mon, 10 May 93 Volume 93 : Issue 120
Today's Topics:
Confused: ARP question....
Confused ARP question...
MX and SMTP routing question. (2 msgs)
updated base KA9Q code
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: 09 May 93 07:24:30 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: Confused: ARP question....
To: <TCP-Group@UCSD.Edu>
I'm playing with a new Internet Gateway in our area and am a bit
puzzled. I've got the following routes defined:
route add 44.28.0/24 14567 # local 2 mtr ip
route add 44.28.1/24 44430 # local 440 ip
route add default 14567 dfwgate # dfwgate.ampr.org on 145.67
Now when I ping uhm.ampr.org, my station sends out an ARP request for
uhm.ampr.org locally. No one answers, so nothing else happens. I send
a couple of ARP request for umh.ampr.org but eventually, it gives up.
I'm pretty sure that the ARP request was not going to dfwgate for
gateway routing.
Should the ARP request be routed through the gateway or should the
gateway answer the ARP request or what? Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
-------------------------------------------------------------------
| "I am Homer, of Borg...prepare to be assim -- ooo, donuts." |
-------------------------------------------------------------------
------------------------------
Date: Sun, 9 May 1993 11:12:02 -0400 (EDT)
From: MIKEBW@ids.net (Mike Bilow, <MIKEBW@ids.net>)
Subject: Confused ARP question...
To: tcp-group@ucsd.edu
From: IDS::MIKEBW "Mike Bilow, <mikebw@ids.net>" 9-MAY-1993 11:03:07.26
To: SMTP%"kf5mg@vnet.IBM.COM"
CC: MIKEBW
Subj: RE: Confused: ARP question....
ARP requests are never routed. They aren't IP frames, so there is no way
to route them except at the link layer. You could, in theory, digipeat
or netrom encapsulate an ARP request, but that's probably a bad idea
except in certain very limited cases.
If you are trying to ARP something that is not directly reachable, then
ARP is not the thing to use. There are kludge solutions, such as having
the gateway which is directly reachable do a "proxy" or "published" ARP
reply for the hidden thing; this is considered reasonable on SLIP, for
example. Another approach is to make a manual ARP entry for the hidden
thing at the sending machine, but that only works for one sender.
In your case, my view is that an ARP error like this is really a result
of a routing error. If you have a direct route to something, it should
be directly reachable and should therefore be able to exchange ARP info
with you (provided that it is on an interface type that supports ARP).
If you are routing via a gateway, NOS should send the ARP request for
the gateway rather than the end target, and this all works in NOS as far
as I know.
-- Mike Bilow, <mikebw@ids.net> (Internet)
N1BEE @ WA1PHY.#EMA.MA.USA.NA (AX.25)
------------------------------
Date: 09 May 93 08:18:21 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: MX and SMTP routing question.
To: <TCP-Group@UCSD.Edu>
I have the following entries set up for dfwgate on UCSD.EDU.
dfwgate.kf5mg IN A 44.28.0.86
dfwgate IN CNAME dfwgate.kf5mg
dfwgate IN MX 10 dfwgate
dfwgate IN MX 20 system200.cecs.unt.edu.
kf5mg IN A 44.28.0.14
kf5mg IN MX 10 dfwgate
This is mostly Greek to me, so if I've done something horrendously
wrong, please let me know. Anyway... when mail is sent to
anyuser@dfwgate.ampr.org it arrives safely. When I send mail to
kf5mg@kf5mg.ampr.org, I never get it. I get a message after three days
that my mailer was unable to deliver the note.
I would like to have mail for kf5mg@kf5mg.ampr.org to be sent to
dfwgate. I'd then either log in to dfwgate from the Internet or run
pop from my nos box to get the mail.
I'm pretty sure that this is possible, but I just don't know how to
make it happen.
If anyone can give me a bit of help and a brief explanation of what
I've done wrong, I'd appreciate it. Thanks.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
-------------------------------------------------------------------
| "I am Homer, of Borg...prepare to be assim -- ooo, donuts." |
-------------------------------------------------------------------
------------------------------
Date: 09 May 93 11:35:48 CDT
From: Jack Snodgrass <kf5mg@vnet.IBM.COM>
Subject: MX and SMTP routing question.
To: <TCP-Group@UCSD.Edu>
I think that I've found my problem. My SMTP server is resolving
kf5mg@kf5mg.ampr.org to dfwgate.ampr.org. Mirrorshades has not be set
up to route 44.28/16 stuff to 129.120.20.219 yet, so when it tries and
makes an smtp connect to 44.28.0.86, it's not working. I either need
to add an additional mx record that points to the 129.120.20.219 address
or wait for mirrorshades to start routing 44.28/16 stuff to my gateway.
If this is wrong, please let me know.
73's de Jack - kf5mg
AMPRnet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
Internet - kf5mg@vnet.ibm.com - home (817) 488-4386
-------------------------------------------------------------------
| "I am Homer, of Borg...prepare to be assim -- ooo, donuts." |
-------------------------------------------------------------------
------------------------------
Date: Mon, 10 May 93 00:51:56 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Subject: updated base KA9Q code
To: tcp-group@ucsd.edu
I've just updated the files in ucsd.edu:/hamradio/packet/tcpip/ka9q.
No earthshattering changes since the last update, just some minor bug
fixes. As always, see the RCS checkin comments for details.
rcsdsrc.zip is a zipped snapshot of my current RCS source tree (minus
certain new files that are Qualcomm proprietary). I'm using the *new*
version of ZIP here; you'll need either PKZIP version 2, or the
freeware equivalent. I've included a copy of the DOS freeware zip.exe
and unzip.exe executables. Note that the freeware ZIP syntax differs
slightly from the PK version; check the help summary.
I've switched to Stu Phillips' port of RCS 5.6, the DOS binaries for
which are in rcs56b.zip. Unlike Stu's DOS port of RCS 5.5, his RCS 5.6
no longer appends "%v" to each RCS file name. So the files in
rcsdsrc.zip have the same names as their checked-out counterparts. To
rebuild NOS, you must unzip rcsdsrc.zip in a subdirectory named RCS.
Then go back up one directory level and manually check out each of the
source files into that directory for compilation. My old makefile had
a rule that automatically checked out source files as needed, but this
doesn't seem possible with the new RCS naming conventions. I'll see if
I can find a way to make this less painful.
I think these RCS files are compatible with the regular UNIX RCS, but
I haven't checked.
When rebuilding, don't use the "config.h" and "makefile" versions in
rcsdsrc.zip. Replace them with the discrete versions of these two
files stored in the ka9q directory. They delete references to unreleased
code and have a more appropriate set of configuration options for packet
radio. The binary in net.exe was compiled with this config.h and makefile.
Note! It is for the 386/486 only! If you want a 286 version, you'll have
modify makefile and rebuild it (I no longer use 286s).
Have fun.
Phil
------------------------------
End of TCP-Group Digest V93 #120
******************************
******************************