My program works just fine when I do
Socket s = new Socket("127.0.0.1", 10000);
But when I replace localhost with my own external IP adress, it fails
What gives? It throws an UnknownHostException immediately, even though I can ping my external IP just fine.
Stack trace:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at java.net.Socket.<init>(Socket.java:375)
at java.net.Socket.<init>(Socket.java:189)
at FileClient.main(FileClient.java:29)
What gives? It throws an
UnknownHostException immediately, even
though I can ping my external IP just
fine. Stack trace:
I don't see an UnknownHostException in your stack trace. The "remote" side actively refuses the connection. Could be because of a firewall, but unlikely, as firewalls usually silently drop packets instead of actively refusing. Most likely, the server application just isn't listening on the external interface. Most server software behave like that in the default configuration due to security reasons. Check what the output of the netstat -n -a command.
If that's your external IP you would need to open/port forward 100000
Related
I'm trying to use JavaMail in order to connect to an IMAP Server (on a remote virtual linux machine - Ubuntu 14 LTS) but I'm getting the following exception:
java.net.ConnectException: Connection refused
I've already tried to establish the connection via Telnet and everything works.
The JavaMail version I'm using is 1.5.5 (also tested with 1.4.7) and I'm using the following properties:
Properties properties = System.getProperties();
properties.setProperty("mail.imap.host", SERVER);
properties.setProperty("mail.store.protocol", "imap");
properties.put("mail.imap.port", PORT);
Session session = Session.getInstance(properties, null);
Store store = session.getStore("imap");
store.connect(USERNAME, PASSWORD);
Notes:
It's working on my personal machine
It's working on another external machine
It's failing on the remote linux virtual machine
The IMAP server is on a different machine - which is accessible to all of the previous
I've done some research and some people told that it could be a firewall/blocking issue but how am I able to connect via Telnet?
Thanks.
Edited
The telnet command I've applied in the test-run:
telnet <server_ip> <port>
After this, the connection is successfuly established and I'm able to apply IMAP commands such as list status.
The output from javamail when it fails is the following:
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:233)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:189)
at com.sun.mail.iap.Protocol.<init>(Protocol.java:107)
at com.sun.mail.imap.protocol.IMAPProtocol.<init>(IMAPProtocol.java:104)
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:538)
... 12 more
Firewalls usually work port based. This means telnet (23/TCP) can be allowed whereas IMAP (usually 143/993) is blocked.
You should check the firewall and check if the IMAP port is open.
Where is your program running? If you change getDefaultInstance to getInstance does it work?
I've found a solution!!
I performed a network capture on the remote machine and I saw that for some reason the javamail api was using the default IMAP folder and not the one I've selected..
Further tests revealed that changing the property value type to String instead of Integer solved this issue. It's important to notice that this didn't happen on other environments so I'm not sure the reason I had to make this change.
My Thread pool is becoming full because, most of the threads are waiting for the socket connection. How to add timeout for jmx connect
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
- locked <0x05671ad0> (a java.net.SocksSocketImpl)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:548)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.<init>(SSLSocketImpl.java:351)
at com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:71)
at javax.rmi.ssl.SslRMIClientSocketFactory.createSocket(SslRMIClientSocketFactory.java:105)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java:97)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:185)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1871)
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1841)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257)
This is a tough one. It depends on which part is timing out due to the environment you are in.
Most probably you are encountering a connect timeout at the TCP level due either firewall issues or a dead application with its socket still up.
The overall connecttimeout for the JVM is set to -1, so infinite by default. Hello thread leaks.
sun.net.client.defaultConnectTimeout (default: -1)
You can find the documentation for Java oracle network parameters here: https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html
The jmx/rmi specific documentation sadly doesn't have a connect timeout setting at that level. But they have a bunch of other controls on the read time-out: https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/sunrmiproperties.html
You can test this while developing with something as simple as using netcat and pointing your app over to the localhost port:
# creat socket on port 3333
netcat -l 3333
# now point your app on the socket
# and you should be able to reproduce
This will stimulate a dead app or firewall block on the port.
Just add the Following System property - "-Dsun.rmi.transport.tcp.responseTimeout=60000"
I am getting
Caused by: java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:564)
at sun.reflect.GeneratedMethodAccessor638.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.SSLProtocolSocketFactory.createSocket(SSLProtocolSocketFactory.java:130)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
javadoc says
Signals that an error occurred while attempting to connect a socket to
a remote address and port. Typically, the remote host cannot be
reached because of an intervening firewall, or if an intermediate
router is down.
Is this error on client side or remote side or it can be either of these?
Basically it says that your client cannot connect to the server due to the address is inaccessible from the client machine.
Please check that the address you are connecting to is accessible, either via ping command in your Command Prompt (Windows) or terminal (Unix-based):
ping <address>
or if it's a web server you can try to check it in your web browser.
The ping command is helpful for me in most cases, since I would know why exactly I can't connect to the address. It can be a mistyped address or like the javadoc suggests, problem with firewall.
Either. It could be a firewall on the client machine blocking outgoing calls or somewhere at the other end.
It may be possible the ping will provide responses, but the application may still fail to connect.
If that is the case, I would suggest using telnet to try and connect to the host using the desired port, telnet host.address port
If the connection is refused then the port on the host will need to be allowed. It that succeeds, but the application still won't connect:
Verify the address:port being used in your application are the same as those used in the telnet test.
It may be a local port on the client blocking the connection, in which case you would need to allow the port on the client
In my case it was solved like this:
1 - Clear the cache with 'yarn cache clean' or 'npm cache clean --force'
2 - after that reboot the pc.
If you clear the cache but do not reboot, the data will still be stored 'somewhere' on the network, so the port will not connect, it is still busy.
After restarting it connects smoothly.
I hope I was helpful!
I had the same issue, and resolve it by disabling the firewall on both sides :
systemctl disable firewalld
service firewalld stop
I had the same issue, I did run iptables flush on host server, this fixed the issue.
# iptables --flush
I have a server, to which a client machine connects. Recently I decided to encrypt the connection with stunnel, so now client program connects not directly to the server, but to localhost:8045 (I checked, and this port is not occupied).
Java code:
URL url = new URL("http://localhost:8045/malibu/GetProviders");
InputStream stream = url.openStream();
And I get the following:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.<init>(Socket.java:366)
at java.net.Socket.<init>(Socket.java:180)
. . .
If I try to request the same page using curl, everything is fine.
What can cause such behavior?
EDIT: Yes, there is a listening socket - running netstat -avn | grep 8045 gives:
tcp6 0 0 ::1:8045 :::* LISTEN
The listening socket is bound to the IPv6 loopback address (::1). I recall some issues with Java not supporting dual-stack IPv4/IPv6 systems correctly; this is probably such a case. It is connecting to 127.0.0.1 only (IPv4).
Everything else you have tried (curl, telnet...) will try the IPv6 address first, and then fall back on the IPv4 address if that fails. That's why they work, while the Java application does not.
Try forcing stunnel to bind to 127.0.0.1. You might also try having Java connect to http://[::1]:8045/malibu/GetProviders, though I can't recall if it supports IPv6 addresses in HTTP URLs.
I have Apache on Windows and also connection refused from Java. However debugging the connection and the Apache log shows, that it is actually not a connection problem. Apache returns error 301, permanently moved. Then it provides a redirection url to non-existing port 8080. So something's wrong with the server configuration, probably ServerName directive uses wrong port. Adding a trailing slash to the requested url fixes the problem. The most useful debugging output in my case was given by wget.
It's possible that the accepted answer does not explain the phenomenon. The reporter himself admitted in a comment that finally he used a url with slash at the end.
I have an odd issue happening when trying to open multiple Input Streams (in separate threads) on Linux (RHEL). The behaviour works as expected on windows.
I am kicking off 3 threads to open https connections to 3 different servers. All three are invalid IP addresses (in this test case), so I expect an NoRouteToHostException for each of them. The first two return these as expected, and quite quickly. (see stack trace below) However the third (and 4th when I tested it that way) do NOT give a no route exception. They wait for ages, and then give a SocketTimeoutException (see other stack trace below). This takes ages to come back, and does not accurately express the connection issue.
The offending line of code is:
reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
Has anyone seen something like this before? Are there multi-threading issues with sockets on REHL or some limit somewhere to how many can connect at once...or...something?
Expected stack trace, as received for first two:
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
Unexpected stack trace, as received on 3rd:
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
Is the linux firewall blocking the connect? If the output of iptables -L is populated that may contain your answer. You can also test by using telnet localhost <portnumber> to check if the port is available. If it is, telnet should say "connected", etc.
If the invalid IP address is blackholed, then no response will come back, and you will get a timeout rather than a "no route to host". The latter relies upon an ICMP error message being received back from the network.
Ah. see now I feel rather silly. Prompted from the responses above I decided to just put the ip addresses into the browser and see what happened. It turns out I was using the following IP addresses:
1.1.1.1
2.2.2.2
3.3.3.3
Unfortunately, 3.3.3.3 IS a valid IP address, which is not responding. So infact it was working fine all along.
I am now using proper non routable IP addresses 10.27.1.1 etc.