Subject: Need help

From: bret <[email-masked]>
Date: Sun, 28 Apr 1996 20:59:12 +0000

How do i get WU-FTPD to listen at a port other than the one specified 
in etc/services???  i am trying to set up an WU-FTPD server for a work 
assignment.  The problem is that i am NOT the superuser for the system 
i am trying to set the FTP server up on, and consequently do not have 
access to etc/services.  This machine already uses an FTP server for 
it's regular business, and this server uses the standard FTP port for 
it's operation.  For the moment, ftptest is not an option, however 
i'll use that if there's nothing else that can be done.
	None of the literature i've seen mentions anything, compile-time or 
execution-time, about how to change the port settings.  Does anyone 
have any suggestions about how i might be able to change these 
settings???  Assume i have access to ports number over 8000.
	Thanx. 

																																																		- bret -

---

From: "W. James Showalter" <[email-masked]>
Date: Sat, 27 Apr 1996 22:40:29 -0400 (EDT)

Bret,

I am not certain what system you are running but on most flavors of unix,
ftpd was designed to be run via the inetd.  Inetd listens on a variety of
ports (specified in inetd.conf) and then forks off and execs the proper
process based on the config file.  The command port is passed to the ftp
daemon during this process.  The ftp daemon can determine the data port
because by definition in the standard, the data port is one less than the
command port.  I believe it would require relatively significant
modifications to do what you want to do because even if you could have
ftpd listen for incoming connections you would also have to add code to
fork and exec a new process while the original listens for other
incoming connections on the command port. 

If you are running SunOS or Solaris you could consult the documentation
on network programmming using sockets.

My recommendation would be to work with the sysadmin and have him or her
put the appropriate port number of your choice in the /etc/services file 
and in the inetd.conf file (if this is appropriate for your system).

The available ports are in the most recent assigned numbers RFC.  It is 
probably RFC 1800 by now.  It can be obtained from the internic via 
anonymous ftp.

Good luck,
Jim

---

From: Mersault <[email-masked]>
Date: Mon, 29 Apr 1996 01:27:41 -0500 (CDT)

... for the advice.  i realized right after i sent the message 
that i had not mentioned the machine i'm working with is running OSF.  
Sorry 'bout that.
	i guess i'm somewhat curious; how is it that it's so easy to 
specify an alternate port for an httpd server but so difficult for an FTP 
server?  You mentioned that it would be necessary to create several 
different processes to allow the original to listen on the command port; 
i'm curious as to why this is the case.  Why not simply have the server 
listen to a port specified in the /etc/services file?  Just wondering.
	Anyway, thanx for the advice; i'll talk to the sysadmin.
	Later...

							- bret -

---

From: Christopher Vickery <[email-masked]>
Date: Mon, 29 Apr 1996 09:42:20 -0400 (EDT)

> listen to a port specified in the /etc/services file?  Just wondering.

	The syntax of a URL allows an optional port number to be specified,
	which makes it easy for browsers to connect to servers that are
	waiting on some port other than 80.  Telnet is another protocol
	where it is easy to use different port numbers -- telnet clients
	take an optional port number on the command line.  I've never
	seen an ftp client that lets the user specify a port number on
	the command line or otherwise.  So, getting an ftp server to listen
	to a nonstandard port number would be only half the battle.

	Why the difference?  Conjecture: telnet can be used for debugging
	other servers, not just for running login sessions, so it is
	"natural" to have it operate on different ports under user control.
	As for http -- well, maybe it was just a smart move on the part of
	the folks at Cern.  It sure makes it nice for assigning my students
	to develop their own web server/browsers.

	Chris

--
Dr. Christopher Vickery, Computer Science Department, Queens College of CUNY
65-30 Kissena Boulevard, Flushing, NY 11367-0904
(718) 997-3500 [voice]; (718) 997-3513 [fax]

Do you know about the League for Programming Freedom?
Contact http://www.lpf.org or [email-masked] for more information.

---

From: "W. James Showalter" <[email-masked]>
Date: Sun, 28 Apr 1996 20:08:41 -0400 (EDT)

Bret,

First, let me say that I am unfamiliar with the OSF platform.  So I can't
really offer any advice on that.  But I will try to clarify my earlier 
message regarding the ftp daemon (as I understand it).

An ftp daemon process could just listen on the command port for an
incoming connection as you asked in your message.  So assume an ftpd is
listening.  An incoming connection is made and ftpd starts doing its
thing.  Now another connection comes in for ftpd. But since the original
listen is now turned into a fully occupied connection, the second user
gets what I refer to as a busy signal (aka refused).  To alleviate this, a
second ftpd must be listening for a subsequent incoming connection. 
Typically, this type of operation is done by the following:  A connection
comes in for ftpd.  Ftpd makes a copy of itself.  One copy handles the
current connection, the other one listens for new connections. Now, to
make things more efficient while adding some complexity, in Unix, a
process know as 'inetd' takes care of listening for practically all
incoming service requests.  Once the inet daemon determines the service
being requested, it makes a copy of itself (like ftpd above) and then
executes the proper daemon process to take over control of the session. 
By doing it this way, only one process, the inet daemon, needs to be run
instead of a single copy of each service daemon process. 

So, in regard to my earlier message, I believe you will find the ftpd
process geared to working with inetd.  Thus, it will not listen on port
21 for incoming connections (inetd does that).

One more thing to tie this up.  Some communications servers should *not*
be run via inetd.  A classic example is a Domain Name System Server.  Part
of the DNS server's responsibility is to maintain a cache of resolved
addresses. If the DNS process (named on Unix) were to go away when it was
finished and only be restarted when a request came in, then no memory
resident cache could be maintained. 

Jim