On Mon, 3 Jun 2002, Rebecca Pakish wrote: - >Do you have nmap ? Try: - > - ># nmap -sT -p 10082 chena - - [root@slaw etc]# nmap -sT -p 10082 slaw.unterlaw.com - - Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) - The 1 scanned port on slaw.unterlaw.com (10.1.7.23) is: closed - - Nmap run completed -- 1 IP address (1 host up) scanned in 1 second - ---- - That doesn't look happy...further investigation revealed: - - [root@slaw etc]# nmap -v slaw.unterlaw.com - - Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ ) - No tcp,udp, or ICMP scantype specified, assuming vanilla tcp connect() scan. - Use -sP if you really don't want to portscan (and just want to see what - hosts are up). - Host slaw.unterlaw.com (10.1.7.23) appears to be up ... good. - Initiating Connect() Scan against slaw.unterlaw.com (10.1.7.23) - Adding TCP port 22 (state open). - Adding TCP port 224 (state open). - Adding TCP port 10083 (state open). - Adding TCP port 111 (state open). - The Connect() Scan took 1 second to scan 1542 ports. - Interesting ports on slaw.unterlaw.com (10.1.7.23): - (The 1538 ports scanned but not shown below are in state: closed) - Port State Service - 22/tcp open ssh - 111/tcp open sunrpc - 224/tcp open unknown - 10083/tcp open amidxtape - ---- - - Where the heck is 10082/tcp amandaidx???
It looks like the 10082 port is really closed and xinetd is not even listening. (IIRC, if ipchains or iptables were blocking it you would get a state filtered but I am not an nmap expert) On the server, try as root: # netstat -atp | grep amandaidx If xinetd is listening you should see something like: tcp 0 0 *:amandaidx *:* LISTEN 804/xinetd This assumes that amandaidx is in /etc/services. To be sure you can try it with the -n option: # sudo netstat -natp | grep 10082 tcp 0 0 0.0.0.0:10082 0.0.0.0:* LISTEN 804/xinetd <snip> - >Try telneting to the port again. Then go to /tmp/amanda and locate - >the amindexd.<bunchanumbers>.debug file. Look in there for a hint. - >There are probably lots of these files so be sure to get the right - >one. (OR just delete all of them before telnetting :-) - - amrecover.bunchanumbers.debug: - amrecover: debug 1 pid 1602 ruid 0 euid 0 start time Mon Jun 3 13:56:07 - 2002 - amrecover: stream_client: connect(10082) failed: Connection refused - cannot connect to slaw.unterlaw.com: Connection refused - amrecover: pid 1602 finish time Mon Jun 3 13:56:07 2002 - ~ On the server side check for the amindexd.<bunchanumbers>.debug file. It will not be there if amindexd is not starting. -- -- Stephen Carville UNIX and Network Administrator DPSI (formerly Ace USA Flood Services) 310-342-3602 [EMAIL PROTECTED]
