FTPD

[Istvan Derka]

We use HPUX-11iv1.6 on HP Itanium Server. We cannot use the ftp server. The server writes an error meassage to the syslog.log files after we try to connect to the ftp server

Data port : 20
exiting on signal 11

and we see the next message in the ftp client:

421 Service not available, remote server has closed connection

What`s the solution for this problem?

Please help me!

Steve Derka
system manager
steve@sze.hu

[Robert-Jan Goossens]

Hi Steve,

Could you check your /etc/services file if someone removed/uncommented ftp ?

ftp-data 20/tcp # File Transfer Protocol (Data)
ftp 21/tcp # File Transfer Protocol (Control)

Hope this helps,
Robert-Jan

[G. Vrijhoeven]

Hi Steve,

Is ftpd enabled in /etc/inetd.conf?
if not enable and do an #inetd -c

Both ports reserved in /etc/services?
20 and 21

Regards,

Gideon

[Bharat Katkar]

Hi Steve,
Also check whether you have blocked ports 20(ftpdata) and 21(ftp) on your firewall/router end.

Regards,

[Jose Mosquera]

Hi,

Also pls check if a ftp deny clause exist into /var/adm/inetd.sec
i.e:
ftp deny *

Rgds.

[Rgomes]

Hi,

I faced the same error a couple of days ago. I sorted out it by putting an IP address of the client station in /var/adm/inetd.sec.

ftp allow

regards,
Richard

[rick jones]

Grep, and a modicum of knowledge about the include files :) can be helpful:

$ grep 11 /usr/include/sys/signal.h
* @(#)B.11.11_LR common/sys/signal.h $Revision: $
# define SIGSEGV 11 /* Segmentation violation */


basically, that means the ftpd died in an unpleasant fashion. Presuming you are running the HP-supplied ftpd, you might check the ITRC for patches.

You might also want to consider getting started on an upgrade from 11i v1.6 (11.22) to 11i v2 (11.23) although I cannot say that would eliminate the SIGSEGV issue, it would be good to be on a more current OS rev.

Now, if you are up for a bit more detective work... you might download a copy of tusc from ftp://ftp.cup.hp.com/dist/networking/tools/ and then when you know that only you are going to be doing new FTP or telnet or whatnot - anything that runs as a child of inetd, use tusc, with the option to follow fork(), and display the pid, and take a system call trace of the inetd starting just before you initiate the ftp session. You might then be able to determine just how far the FTPD gets before it goes belly-up. That would probably be of great assistance to the Response Centre when you call them (after seeing there isn't already an ftp patch) to report the bug in the FTPD.