ftp failure from VMS to Unix system - unix

When my customers are trying to transfer the files through ftp system, they are getting this error. It seems like the ftp connection is established however because of some unknown reasons the data is not transferring. This is a connection from VMS system to a Unix server.
230 User 1234567 logged in
bin
200 PORT command successful.
hash
Hash mark printing on (1024/hash mark).
put abc.str
200 PORT command successful.
150 Opening BINARY mode data connection for abc.str
%TCPIP-E-FTP_DATACONF, cannot establish data connection with remote host
-SYSTEM-F-REJECT, connect to network object rejected
226 Transfer complete.
421 Service not available, Remote server has closed the connection

If you use VMS FTP then use:
set passive on
before you start the data connection.
If you use VMS COPY /FTP then use:
copy /ftp/passive
to use passive mode.
For more information, see
ftp> help set passive
and
$ help copy /ftp

Related

ODBC connection to OpenEdge 10.2B

I can't tune ODBC connection in ODBC Data Source Administrator using IP or host name of server. Only with localhost using.
Although I can successfully ping the server via IP or host name.
Firewall is tuned-of.
OpenEdge 10.2B is installed at Win Server 2003
The error I got:
[DataDirect][ODBC Progress OpenEdge Wire Protocol driver]Connection refused. Verify host name and port number ErrNum=10038
I am sssuming you clicked "Test Connect"? Is your database really named TEMP? That seems unlikely.
"Administrator" is also an unusual name for a user of the db. "sysprogress" is more typical (although you should certainly setup a non-default userid.)
So far you have shown roughly half of the configuration required to make this work. Your DSN setup isn't obviously wrong but if it does not match a running database that is listening on port 3333 at that IP address then you will get this error.
The next useful thing that you could do to clarify the problem is to show the database configuration and demonstrate that you have a properly configured broker running and listening for connections on port 3333.
check list:
1、you must start your openEdge database
$DLC/bin/_mprosrv {database-full-path} -L 8000 -c 350 -B 1000 -N TCP -S {Port} -n 100
2、check Firewalls rule
3、use userID : SYSPROGRESS password :SYSPROGRESS to test odbc connect

Qt connecttohost command showing connection refused from remote host

I am running an application in WEC 7 and trying to connect to remote system, and I am using QFtp for transferring some data. When I try to connect to remote host using connecttohost, I am able to find the host but the connection is not successful and shows me error connectionrefused from remote host.
I tried the following things :
I made an exception in firewall for ftp connections so that remote host can accept the connections.
I turned on the discovery for the folders.
I added an inbound rule for port 21
I checked the option for ftp in control panel/Programs/program and features/turn on windows features/internet information services ,
FTP server.

failed to add munin node to monitoring

I'm trying to setup some new hosts in munin for monitoring. For some reason it ain't happening!
Here's what I've tried so far.
On the munin server, which is already monitoring several other hosts, I've added the host I want in /etc/munin/munin.conf
[db1]
address 10.10.10.25 # <- obscured the real IP address
use_node_name yes
And on the db1 host I have this set in /etc/munin/munin-node.conf
host_name db1.example.com
allow ^127\.0\.0\.1$
allow ^10\.10\.10\.26$
allow ^::1$
port 4949
And I made sure to restart the services on both machines.
From the monitoring host I can telnet to the new server I want to monitor on the munin port:
[root#monitor3:~] #telnet db1.example.com 4949
Trying 10.10.10.26...
Connected to db1.example.com.
Escape character is '^]'.
# munin node at db1.example.com
Wait a few minutes.. and nothing! The new server won't appear in the munin dashboard on the munin monitoring host.
In the /var/log/munin/munin-update.log log on the db1 host (the one I'm trying to monitor) I find this:
2015/11/30 03:20:02 [INFO] starting work in 14199 for db1/10.10.10.26:4949.
2015/11/30 03:20:02 [FATAL] Socket read from db1 failed. Terminating process. at /usr/share/perl5/vendor_perl/Munin/Master/UpdateWorker.pm line 254.
2015/11/30 03:20:02 [ERROR] Munin::Master::UpdateWorker<db1;db1> died with '[FATAL] Socket read from db1 failed. Terminating process. at /usr/share/perl5/vendor_perl/Munin/Master/UpdateWorker.pm line 254.
What could be going on here? And how can I solve this ?
Since you have already verified that your network connection is ok, as a first step of investigation, I would surely simplify the munin-node.conf. Currently you have:
host_name db1.example.com
allow ^127\.0\.0\.1$
allow ^10\.10\.10\.26$
allow ^::1$
port 4949
From these I would remove:
host_name (it is probably redundant.)
The IPv6 loopback address. (I don't think you need it, but you can add it back later if you do need it)
The IPv4 loopback address. (same as above)
If it still not working, you could completely outrule any issue with the allow config by replacing the direct IPs with:
cidr_allow 10.10.10.0/24
This would allow connection from a full range of IPs in case your db1 host appears to be connecting from a different IP.

The server rejected SFTP connection, but it listens for FTP connections

When I use WinSCP in Windows to connect to VMware with Ubuntu, it prompted this:
The server rejected SFTP connection, but it listens for FTP connections.
Did you want to use FTP protocol instead of SFTP? Prefer using encryption.
What's the matter?
I can succeed to ping Ubuntu in Windows.
The fact that you can ping the server has nothing to do with what protocols it supports.
The message says that the server does not listen on port 22 (SSH, SFTP), but listens on port 21 (FTP). The point of the message is that WinSCP defaults to SFTP protocol, what is not common. So it tries to help users who expect FTP to be a default. But that's not relevant to you apparently.
As #ps2goat suggested, make sure you setup SSH/SFTP server.
For more details, see the documentation for the error message The server rejected SFTP connection, but it listens for FTP connections.
If you see this error all of a sudden (when SFTP has always worked for you for this particular server), and if you are using CSF (ConfigServer Security & Firewall), then it might be that your IP was blocked for SSH access. Try flushing all blocks. Also, try restarting the SSH server.
Old question but still responding so others might get benefited.
I stumbled upon this error and the first thing I checked was if my ubuntu machine had ssh installed. It was there and the latest version and I still would get this error.
As long as you have ssh access to the target, check the ssh service status and most certainly it'd be found inactive. Turn it on using
sudo service ssh restart
and you should be back in the game.
Do check the status of the SFTP by using
sudo service ssh status
and take any corrective action.

How to use FTP get/put from Solaris to IBM Mainframe?

For some reason when I try to use get or put from a Solaris box to an IBM mainframe, the ftp client appears to hang.
I've tried all sorts of different variations (for example, including using quotes and not), and all I ever get is a "200 Port Request OK". But I never get the prompt back, and eventually the connection breaks.
ftp> open ibm.some_server
Connected to ibm.some_server
230 USER1 is logged on. Working directory is "USER1.".
Remote system type is MVS.
ftp> cd 'Z.TABS.'
250 "Z.TABS." is the working directory name prefix.
ftp> get 'SAMASCPY' samas.txt
200 Port request OK.
Anyone know what could be going on?
You need to enable passive mode. With Solaris 10's ftp:
ftp> passive
Passive mode on.
The FTP protocol as originally defined makes the server open a connection back to the client when a file transfer is initiated. That's what the PORT command in your question shows -- the client requested that the server connect back to its address on a specific port number. These days, with ubiquitous firewalls & NAT traversals, that rarely works.
Enabling passive mode tells the client to connect directly to the server, and fixes this issue. Most ftp clients now use passive mode by default; Solaris' does not.

Resources