rlb@RTPVV1.RTP.SEMI.HARRIS-ATD.COM (Bob Boyd (919)549-3627) (02/09/90)
Message Created @ 8-FEB-1990 13:11:18.96
As you've seen over the last few days, I've had some interesting times
with the PMDF configuration I'm setting up.
I now have PHONENET working with a MUX arrangement. The Local channel
works just fine. The Decnet-Mail channel is working nicely.
The FTCP (Fusion TCP/IP) channel is only working on the slave
side -- incoming mail is received and processed properly. The master
side of FTCP is dying when it goes out to establish connection with
the target system.
The local Fusion setup is to run as a caching only and/or slave
name-server. It appears that something is going wrong in the
name to address conversion. I've looked at the code a little bit
and it appears that the call to "name2adr" is failing. Does this
code only look up names in the local MACHINE.DB? Is there some
way to fix up this code to use the name server that has been
defined (and appears to work for TELNET & FTP)?
My next stab in the dark will be to try setting up an FTCP Gateway
and define the gateway system in the MACHINE.DB file. In my next
message I'll report on my success using this. Obviously some of
you out there have this stuff working nicely or it wouldn't have
been in the distribution. I'd like to have it work for me too.
I have not tried the WIN/TCP slave replacement, but I've tried using
the master portion and it dies with some kind of error.
Is there anyone who can and is WILLING to help me figure out what's
going wrong with my setup?
-----------------------------------------------------------------
Bob Boyd
Harris Microelectronics Ctr.
POB 13049, MS 7T3-01
RTP, NC 27709-3049 Voice: (919)549-3627
Internet: rlb@rtpvs2.rtp.semi.harris-atd.com, or
rlb@rtpvv1.rtp.semi.harris-atd.com
BitNet: rlb%rtpvs2.rtp.semi.harris-atd.com@cunyvm.cuny.edu, or
rlb%rtpvv1.rtp.semi.harris-atd.com@cunyvm.cuny.edu
Harris DECnet: RTPARK::RLBNED@HMCVAX.CLAREMONT.EDU (Ned Freed, Postmaster) (02/09/90)
Bob Boyd writes: > As you've seen over the last few days, I've had some interesting times > with the PMDF configuration I'm setting up. > I now have PHONENET working with a MUX arrangement. The Local channel > works just fine. The Decnet-Mail channel is working nicely. > The FTCP (Fusion TCP/IP) channel is only working on the slave > side -- incoming mail is received and processed properly. The master > side of FTCP is dying when it goes out to establish connection with > the target system. > The local Fusion setup is to run as a caching only and/or slave > name-server. It appears that something is going wrong in the > name to address conversion. I've looked at the code a little bit > and it appears that the call to "name2adr" is failing. Does this > code only look up names in the local MACHINE.DB? Is there some > way to fix up this code to use the name server that has been > defined (and appears to work for TELNET & FTP)? My documentation for Fusion is at V3.2, with field test notes for V3.3. It says nothing about domain name service support in name2adr, but the field test notes indicate that domain name service was implemented in all programs. Most other implementations of TCP/IP implemented it at a low enough level so that routines like name2adr picked up the support, but I'm not sure about Fusion in this regard. My last experience with Fusion ended when our field test agreement expired, and I have been unable to renew this agreement. This means that I cannot offer the testing and support I'd like to for this channel program. We simply cannot afford to purchase every implementation of TCP/IP out there. Let's backtrack and break down this situation a little more. There are four levels of "registration" a system can have on your machine. The first is to be hardcoded into your MACHINE.DB (or HOSTS.TXT, or whatever) file. This means that hostname to IP address is simply a database lookup. I know that the Fusion channel works properly in this regard -- this is how I have used it myself. The second level is no entry in MACHINE.DB, but there's an A record in your name server database. This should definitely be equivalent to a hardcoded entry in MACHINE.DB. The third level is an entry in someone else's name server database. If things are set up correctly and if the implementation of Fusion is similar to other TCP/IP's, this should also work -- name2adr should do the nameserver lookups and get the IP address. Failure may indicate a problem with the name server, configuration, or a number of other things. The simplest check is to see if you can FTP or TELNET to the remote system in question. If you can, the domain name server is working properly, and name2adr is not returning name server information. The fourth level is when a system has no direct connection to the network, but has indirect access via some other system that is on the network. In this case an MX record in the domain name database points at the relay system. The Fusion channel program does not support this sort of access -- at present the only channel programs in PMDF that do are the Multinet, Wollongong, and CMU ones. Adding code to the Fusion channel to do this would require access to a current version of the Fusion software. I don't have access to this, so I cannot do it. No other site has volunteered to do it (or has even indicated an interest, for that matter), so I have not considered this to be a high priority work item. > My next stab in the dark will be to try setting up an FTCP Gateway > and define the gateway system in the MACHINE.DB file. In my next > message I'll report on my success using this. Obviously some of > you out there have this stuff working nicely or it wouldn't have > been in the distribution. I'd like to have it work for me too. There are several sites using Fusion that I know of. One seems to be happy with it on the Internet, despite the lack of MX record support (they may use it in a slave mode of some kind). Another one only uses it on an internal network, where they don't run name servers of any kind. There are probably more, but it is hard for me to tell. > I have not tried the WIN/TCP slave replacement, but I've tried using > the master portion and it dies with some kind of error. I'm not sure what you mean by this. If you put up Wollongong TCP/IP and tried the channel program but it failed, please provide more information on how it failed. If you did not install an alternate TCP/IP, there's no way it will work -- the $QIO interface (and the device name, for that matter) is completely different. There are a lot of sites using both Wollongong and Multinet TCP/IP (which are $QIO compatible). I'm one of them, in fact. I don't know of any outstanding problems with the Wollongong/Multinet channel program, apart from a bug in the Wollongong libraries that necessitates linking with an older version of those libraries for proper operation. I believe Wollongong has fixed this recently, but I could be wrong about this. > Is there anyone who can and is WILLING to help me figure out what's > going wrong with my setup? I'm game, but I'm hampered by my inability to recreate your environment to the point of being able to reproduce your problem. I'm sorry I did not get around to your message until now -- the info-pmdf list has been pretty active recently and I'm a little behind. Ned
KVC@FRIDAY.A-T.COM (Kevin V. Carosso) (02/09/90)
I wrote the Fusion TCP/IP channel for PMDF back when I was working at
NRC. It should be using name2adr() just like all the other Fusion
utilities. If the logical name FNS_NAME_SERVER is defined to be "BIND",
it ought to use the resolver, if not then it will use MACHINE.DB. I
remember something about looking in MACHINE.DB first if we are using
the resolver, allowing for aliases and shortform names without generating
a resolver query. In any case, it ought to work the same as any other
Fusion utility.
It might be that they've changed something since I left (over a year ago)
that breaks the FTCP_LOCAL master channel code. I used PMDF when I was at
NRC, but I doubt if they do now. We don't run Fusion so we cannot really
support it very well. We do run TGV MultiNet, which pretty much assures
that PMDF will work best with that. Since Wollongong is has the same
interface as MultiNet, PMDF does well with that too.
/Kevin Carosso kvc@friday.a-t.com
Innosoft kvc@ymir.bitnet
ps. Oh, by the way -- the Fusion channel does not support MX records.
I didn't have time to do that between the time I got the BIND
resolver/server working for NRC and the time I left. Perhaps someone
else has done so?