Eclipse Neon with Bluemix Liberty Plugin and WLP tools installed is throwing the following error at the Eclipse console (every 5 seconds):
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
proxy: error connecting to 75.126.XXX.XX:8081: dial tcp 75.126.XXX.XX:8081: i/o timeout
Note: The log doesn't actually show X's in the IP, the full IP has been hidden.
The error started right after adding and removing a second WLP server instance using the WebSphere Liberty Tool plugin. Is it possible to fix it at the configuration side?
This was a temporary issue with the loggregator service. It should be working fine now.
Related
new to linux world.
I have setup two apache webserver , one haproxy and one testpc.
I am able to curl web server with index.html contents on port 80.
but when i try to curl haproxy on any port or port 80 i am getting curl:
(7) Failed connect to 35.229.60.183:80; Connection refused
firewall is turned off on all the servers, restarted the haproxy.
haproxy config file :
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 100s
maxconn 3000
frontend myserver
bind *:80
default_backend mybackendserver
mybackendserver
balance roundrobin
mode http
server webserver 35.185.18.206:80 check
server webserver1 35.231.241.247:80 check
when I try to curl them in my test machine i am getting curl:
(7) Failed connect to 35.229.60.183:80; Connection refused
35.229.60.183 is the ip of my haproxy server.
If I recall correctly, you should enable the port :80 or whatever you use, directly from the Google Cloud dashboard.
Check this out.
I am having HAProxy in front of TCP servers like Postgres, Mongo and logstash. I am able to establish TCP connection but the connection will timeout after several minutes. Errors I'm getting are like
Mongo::Error::SocketTimeoutError, Socket request timed out
and
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
What can I do to keep TCP connection alive?
Will this help?
option srvtcpka
When Packer reaches the "Waiting for SSH to become available..." step.
My logs show
14:07:29 [INFO] Attempting SSH connection...
14:07:29 reconnecting to TCP connection for SSH
14:07:29 handshaking with SSH
14:07:29 handshake error: ssh: handshake failed: read tcp 127.0.0.1:60372->127.0.0.1:3057: read: connection reset by peer
14:07:29 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:60372->127.0.0.1:3057: read: connection reset by peer
14:07:36 [INFO] Attempting SSH connection...
14:07:36 reconnecting to TCP connection for SSH
14:07:36 handshaking with SSH
14:07:36 handshake error: ssh: handshake failed: read tcp 127.0.0.1:60376->127.0.0.1:3057: read: connection reset by peer
14:07:36 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:60376->127.0.0.1:3057: read: connection reset by peer
Note a different port on each attempt.
60372
60376
Packer is trying a new port, every 7 seconds.
Is there a way to configure the ports before or during the build to avoid this try/fail approach?
That is the source port which the ssh connection is made from. It's assigned by the OS with a random available high port.
The issue is not with SSH Server or TCP/IP. It is with the way Packer is designed.
When a VM is created, Packer.io will run boot commands. It takes time and time varies on different machines. During that time you will see "Waiting for SSH to become available...". On the background, Packer.io will be attempting to establish an SSH connection. The log is saturated with messages like this
Linux
14:07:29 [INFO] Attempting SSH connection...
14:07:29 reconnecting to TCP connection for SSH
14:07:29 handshaking with SSH
14:07:29 handshake error: ssh: handshake failed: read tcp 127.0.0.1:60372->127.0.0.1:3057: read: connection reset by peer
14:07:29 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:60372->127.0.0.1:3057: read: connection reset by peer
or
Windows
15:54:31 packer.exe: 2017/02/01 15:54:31 [INFO] Attempting SSH connection...
15:54:31 packer.exe: 2017/02/01 15:54:31 reconnecting to TCP connection for SSH
15:54:31 packer.exe: 2017/02/01 15:54:31 handshaking with SSH
15:54:31 packer.exe: 2017/02/01 15:54:31 handshake error: ssh: handshake failed: read tcp 127.0.0.1:62691->127.0.0.1:4289: wsarecv: An existing connection was forcibly closed by the remote host.
15:54:31 packer.exe: 2017/02/01 15:54:31 [DEBUG] SSH handshake err: ssh: handshake failed: read tcp 127.0.0.1:62691->127.0.0.1:4289: wsarecv: An existing connection was forcibly closed by the remote host.
OS will boot and with it SSH server on the guest will become available. At that moment SSH connection from host to guest should establish.
Reproduced and Confirmed on Windows 10 Pro and Ubuntu 16.04.1 TLs
I've got nginx 1.9.7 compiled against OpenSSL 1.0.2e running on Ubuntu 14.04.3 LTS (3.13.0-71-generic x86_64). I can connect to it with a browser no problem at all, and get a secure connection.
I also have a client who is running some Windows Server and is trying to connect to using WCF. They report they aren't able to connect to my service.
My nginx error log shows:
2015/12/09 17:38:27 [info] 10750#0: *6494 recv() failed (104: Connection reset by peer) while SSL handshaking, client: {REDACTED}, server: 0.0.0.0:443
Digging deeper, a Wireshark dump shows this pattern:
Client -> Server [SYN]
Client <- Server [SYN, ACK]
Client -> Server [ACK]
Client -> Server [RST, ACK] (connection closes)
Sniffing a successful request shows:
Client -> Server [SYN]
Client <- Server [SYN, ACK]
Client -> Server [ACK]
Client -> Server [PSH, ACK] (sends SSL Client Hello)
I'm not really a TCP guy, so I'm a little out of my depth in understanding what could be happening here. Any advice would be appreciated.
Turns out that the problem was the client's firewall :(
Edited to add detail: the client's firewall had been configured to block the domain and was therefore dropping the TCP connection as soon as it was established. Once the block was cleared, the issue went away.
I have a browser based application which displays an RTMP stream.
The RTMP stream url is similar tortmp://xxx.xxx.xxx.xxx:1935/oflaDemo/livestream.flv
I can view the live stream from my home network. But from my office, I am unable to view the stream. I am getting the following error: Error Loading Stream: Could not connect to server.
My office has a firewall running having only few specific ports open like 80, 443, 8443 etc.
My questions are
1) Is this a firewall issue ?
2) If yes, what ports should I ask them to open ?
3) How could I be sure that this is a port blocking issue ?
Yes, I think it's a firewall issue
RTMP uses the TCP port 1935
Here is the output with my environment:
Flash Plug-in Version: WIN 16,0,0,305
RTMP DEFAULT Success
RTMP 80 Success
RTMP 443 Failed
RTMP 1935 Success
RTMPT DEFAULT Success
RTMPT 80 Success
RTMPT 443 Failed
RTMPT 1935 Success
RTMPE DEFAULT Success
RTMPE 80 Success
RTMPE 443 Failed
RTMPE 1935 Success
It seems that port 443 doesn't work for me, I don't know why.
It might be.
The RTMP protocol has multiple variations:
The "plain" protocol which works on top of and uses TCP port number 1935 by default.
RTMPS which is RTMP over an TLS/SSL connection.
...
– Wikipedia: Real Time Messaging Protocol