On Thu, 23 Nov 2000, Nathan Neulinger wrote:
> "Brandon S. Allbery KF8NH" wrote:
> >
> > On Thursday, November 23, 2000 11:43 +0100, Harald Barth <[EMAIL PROTECTED]>
> > wrote:
> > +-----
> > | I don't think your NAT box will be able to determine where to deliver
> > | callbacks from your server on the public side to your client on the
> > | private side. In spite of it appearing to work (especially reads) in
> > | the beginning, you will probably loose in the long run and you will
> > | miss file updates.
> > +--->8
> >
> > Actually, it works quite well as long as you set the masq timeout for port
> > 7003/udp (IIRC) to be effectively infinite. We have 75 compute servers
> > behind a NAT/ipmasq gateway which has been so modified, they've been
> > working fine for several years.
> >
> > This will, of course, chew up a lot of ports on the gateway if you have
> > more than a few machines behind it.
>
> So the client/server isn't dependent on the source port being correct?
> I've noticed that the source port almost always is in the 7000-7003
> range as well. I guess the server doesn't care?
The various AFS servers (fileserver, ptserver, vlserver, etc) all live on
well-known ports. They will accept connections from any client port, but
anything that makes a requestto the afs3-fileserver service (port 7000)
must implement the afs3-callback service on the same port from which its
requests originate. For example, the cache manager always provides the
callback service on port 7001, so that is also the port from which its
requests originate (*). Very few user-mode programs talk to the
fileserver directly, but those that do, like scout, always originate their
requests from a fixed port. This is because as shipped, Rx does not
provide an interface that allows an Rx service to be started on a randomly
assigned port.
(*) Note that when you rxdebug a fileserver, the connections that you see
"from" port 7002 are really connections _to_ port 7002 on some dbserver.
These are the connections the fileserver uses to look up group membership
information.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
