I am using Indy to connect to an Ftp server. We have had problems with the server being down, creating a "Host not found" error, which I handle and indicate to the user, however, today the software was installed on a computer that did not have an internet connection. The error produced when I "Connect" is also "Host not found", which is not totally correct. Is there a function/procedure I can call inside the TIdFtp component that will tell me if there is actually a connection to the internet so I can display an error indicating the user is not connected? I am using Delphi XE Seattle.
I have looked through the list of IdFtp properties/functions etc, but nothing seems obvious.
Is there a function/procedure I can call inside the TIdFtp component that will tell me if there is actually a connection to the internet so I can display an error indicating the user is not connected?
No. What you will have to do is attempt a TCP connection to several different servers and see if any of them succeed or if they all fail. For instance, you can use TIdTCPClient to connect to well-known server ports that are pretty much guaranteed to be online 99+% of the time, like google.com/yahoo.com on port 80 (HTTP) or 443 (HTTPS), etc.
Related
I am setting up port scanner for remote server in my application using Go. I am using DialTimeout function in Go net package to check whether a remote host port is opened or not. The result is fine with success case. But, if i/o timeout happens, I need to identify whether
The port is closed (No service is running) or
Port is blocked (Firewall filtered) or
Due to internet connectivity down in local system where the application is running.
Have tried nmap cli command, I can able to differentiate those failure 3 cases exactly.
nmap command tried: nmap -sA -p port_number host_ip
I found a Go 3rd party libray to use nmap.
But, I don't want to use nmap in my application. Are there any other alternatives in Go to exactly differentiate those 3 cases?
In the simple world
Lets assume you want to scan a Linux system.
If you get an ICMP message type 3 code 3, the firewall explicitly told you:
Hi, I am the firewall of your target host. The host is running. I hereby inform you that you (potentially amongst others) can not access this port. So now that you know you should quit your connection attempts. However, I won't tell you wether it is because there is no service running behind it (in which case my response is simply a courtesy) or because I was told to deny you access. Goodbye!
The port is closed if you do not get above answer and can not make a connection. I hence strongly advice to use context.WithTimeout to make a connection.
In the real world
However, this only applies if the admin of the target host did not change the ICMP message type to respond with - or chose just to drop any packets coming from sources which are not allowed to access the respective service. In the latter case, there is no way for you to know wether the port is closed or filtered.
All of the above only applies if we are talking of an iptables based firewall on the target system with default settings.
Now assume something which is by far more likely: A border firewall plus a local firewall. The border firewall might send other ICMP messages (or, again, simply drop your packages). Those rules apply additionally to the rules of the local firewall. So it is a misconception that you are actually scanning a host. It is more accurate to say that you scan the services reachable via a specific IP.
EDIT
Why would one send an ICMP message explicitly rejecting connection attempts?
There are various reasons to come to that decision. There is a good answer on serverfault.com
Why does Apache-Commons-Net's FTPClient sometimes make the wrong computation for the port number in the PORT command? This is in active mode. For example FTPClient it could send out
PORT <some>,<ip>,<address>,<here>,235,181 when in fact the port number used is 60340. What's the cause for this wrong computation?
This could happen on version 3.3.
I know ftpClient.enterLocalPassiveMode(); could solve this, but I want to know the part where the active mode doesn't work as expected.
From your comments, I assume you mistake an FTP control connection with a data connection.
I assume that the 60340 is local port of the FTP control connection. When opening data connection, 60341 is assigned (hence the PORT ...,235,181).
Reasoning: In an FTP active mode, the client opens listening port for the expected data connection, which it then reports to the server via PORT command over an existing control connection. If the server cannot connect to the port, no TCP/IP packet can ever come to that port. As you claim that the "two machines still communicate at port 60340", it must be the control connection. There cannot be any communication on port, if the connection failed ("Can't open data connection").
The actual cause of the "Can't open data connection" error is likely that you are behind a firewall, so the server cannot connect back to the client. What is a common nowadays. That's what passive mode is good for.
Most proxy servers perform the job of forwarding data to an appropriate "real" server. However, I am in the process of designing a distributed system in which when the "proxy" receives a TCP/IP socket connection, the remote system actually connects with a real server which the proxy nominates. All subsequent data flows from remote to the real server.
So is it possible to "forward" the socket connection request so that the remote system connects with the real server?
(I am assuming for the moment that nothing further can be done with the remote system. Ie the proxy can't respond to the connection by sending the IP address of the actual server and the remote connections with that. )
This will be under vanilla Windows (not Server), so can't use cunning stuff like TCPCP.
I assume your "remote system" is the one that initiates connection attempts, i.e. client of the proxy.
If I get this right: when the "remote system" wants to connect somewhere, you want the "proxy server" to decide where the connection will really go ("real server"). When the decision is made, you don't want to involve the proxy server any further - the data of the connection should not pass the proxy, but go directly between the "remote system" and the "real server".
Problem is, if you want the connection to be truly direct, the "remote system" must know the IP address of of the "real server", and vice versa.
(I am assuming for the moment that nothing further can be done with
the remote system. Ie the proxy can't respond to the connection by
sending the IP address of the actual server and the remote connections
with that. )
Like I said, not possible. Why is it a problem to have the "proxy" send back the actual IP address?
Is it security - you want to make sure the connection really goes where the proxy wanted? If that's the case, you don't have an option - you have to compromise. Either the proxy forwards all the data, and it knows where the data is going, or let the client connect itself, but you don't have control where it connects.
Most networking problems can be solved as long as you have complete control over the entire network. Here, for instance, you could involve routers on the path between the "remote system" and the "real client", to make sure the connection is direct and that it goes where the proxy wanted. But this is complex, and probably not an option in practice (since you may not have control over those routers).
A compromise may be to have several "relay servers" distributed around the network that will forward the connections instead of having the actual proxy server forward them. When a proxy makes a decision, it finds the best (closest) relay server, tells it about the connection, then orders the client to connect to the relay server, which makes sure the connection goes where the proxy intended it to go.
There might be a way of doing this but you need to use a Windows driver to achieve it. I've not tried this when the connection comes from an IP other than localhost, but it might work.
Take a look at NetFilter SDK. There's a trial version which is fully functional up to 100000 TCP and UDP connections. The other possibility is to write a Windows driver yourself, but this is non-trivial.
http://www.netfiltersdk.com
Basically it works as follows:
1) You create a class which inherits from NF_EventHandler. In there you can provide your own implementation of methods like tcpConnectRequest to allow you to redirect TCP connections somewhere else.
2) You initialize the library with a call to nf_init. This provides the link between the driver and your proxy, as you provide an instance of your NF_EventHandler implementation to it.
There are also some example programs for you to see the redirection happening. For example, to redirect a connection on port 80 from process id 214 to 127.0.0.0:8081, you can run:
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
For your proxy, this would be used as follows:
1) Connect from your client application to the proxy.
2) The connection request is intercepted by NetFilterSDK (tcpConnectRequest) and the connection endpoint is modified to connect to the server the proxy chooses. This is the crucial bit because your connection is coming from outside and this is the part that may not work.
Sounds like routing problem, one layer lower than TCP/IP;
You're actually looking for ARP like proxy:
I'd say you need to manage ARP packets, chekcing the ARP requests:
CLIENT -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP
Then normal socket connection via TCP/IP from client to server.
stupid problem. I get those from a client connecting to a server. Sadly, the setup is complicated making debugging complex - and we run out of options.
The environment:
*Client/Server system, both running on the same machine. The client is actually a service doing some database manipulation at specific times.
* The cnonection comes from C# going through OleDb to an EasySoft JDBC driver to a custom written JDBC server that then hosts logic in C++. Yeah, compelx - but the third party supplier decided to expose the extension mechanisms for their server through a JDBC interface. Not a lot can be done here ;)
The Symptom:
At (ir)regular intervals we get a "Address already in use: connect" told from the JDBC driver. They seem to come from one particular service we run.
Now, I did read all the stuff about port exhaustion. This is why we have a little tool running now that counts ports and their states every minute. Last time this happened, we had an astonishing 370 ports in use, with the count rising to about 900 AFTER the error. We aleady patched the registry (it is a windows machine) to allow more than the 5000 client ports standard, but even then, we are far far from that limit to start with.
Which is why I am asking here. Ayneone an ide what ELSE could cause this?
It is a Windows 2003 Server machine, 64 bit. The only other thing I can see that may cause it (but this functionality is supposedly disabled) is Symantec Endpoint Protection that is installed on the server - and being capable of actinc as a firewall, it could possibly intercept network traffic. I dont want to open a can of worms by pointing to Symantec prematurely (if pointing to Symantec can ever be seen as such). So, anyone an idea what else may be the cause?
Thanks
"Address already in use", aka WSAEADDRINUSE (10048), means that when the client socket prepared to connect to the server socket, it first tried to bind itself to a specific local IP/Port pair that was already in use by another socket, either an active one or one that has been closed but is still in the FD_WAIT state. This has nothing to do with the number of ports that are available.
I'm having the same issue on a Windows 2000 Server with a .Net application connecting to a SQL Server 7.0. There's like 10 servers with the same configuration and only one is showing this error several times a day. With a small test program I'm able to reproduce the error by just establishing a TCP connection on the SQL Server listening port. Running CurrPorts (http://www.nirsoft.net/utils/cports.html) shows there's still plenty of available ports in range 1024-5000.
I'm out of ideas and would like to know if you've found a solution since you've posted your question.
Edit : I finally found the solution : a worm was present on the server (WORM_DOWNAD.A) and exhausted local ports without being noticed.
I've been trying to get sqlplus to connect to Oracle from my OS X machine. I asked another question about it here.
One person suggested that I try telnet. Consulting the man page, I tried:
[ ethan#gir ~ ]$ telnet DBHOST:1521
Trying xxx.xxx.xxx.xxx...
telnet: connect to address xxx.xxx.xxx.xxx: Operation timed out
telnet: Unable to connect to remote host
Also...
[ ethan#gir ~ ]$ telnet DBHOST 1521
...with same result.
I'm not sure how to interpret these results. Seems like what you'd expect in any case. You wouldn't do this...
$ ssh some_mysql_host:3306
How is telnet to Oracle different?
Or maybe I didn't understand what they meant.
If anyone could help me understand how one uses telnet to test a connection to Oracle I would be grateful.
They're proposing use of telnet simply because it's one of the simplest TCP/IP clients and because it's installed almost everywhere. It's just an easy way to check from the command line whether you're actually able to make a TCP/IP connection to any particular service.
Also, on many of the ASCII based IP protocols it's straight forward to actually interact with the server to check its working by typing in commands and looking at the responses - I've done this numerous times myself with SMTP servers.
In your case, as you're getting a timeout, either the whole host is down, or the access to that particular host or service is being blocked by a firewall. If you can reach the server with a ping then the latter is more likely.
There's also an outside chance that your name resolution is actually taking you to the wrong host, but you should be able to confirm that by looking at the IP address that telnet said it was trying to connect to.
Another common response is "connection refused". That means that the host is up, but that there's no service running on the specified port.
Basically when you specify a port number e.g
Telnet myserver 1521
It will try to connect to the machine on that port. If you see any data returned or even a blank console then it has connected. If you receive an unable to connect message then the machine is not listening on that port or a firewall is blocking the connection.
Your attempt to telnet to dbhost 1521 getting 'unable to connect' with a timeout suggests that either your hostname resolution for 'dbhost' is giving you the wrong answer, or that host is offline, down or you have network problems.
If oracle was working, you'd get a connection. You wouldn't really be able to do anything with it, but it would confirm that oracle was up and listening.
Oracle instance is not connected from other systems, while it is connected from localhost, I think port is not opened and it is showing problem to telnet 1521 port from other system.
Why not do it the 'right' way? Telnetting to some arbitrary network port will not give you correct information, if the database and it's listener is working correctly.
Just install the oracle instantclient software and use the configuration wizard.