I'd like to start a Tomcat debug session on my remote host from Eclipse, but it fails with this error:
Failed to connect to remote VM
com.sun.jdi.connect.spi.ClosedConnectionException
My Tomcat is, I think, correctly configured to received debug session on port 8000:
tomcat 18771 1 1 17:18 ? 00:00:16 /usr/lib/jvm/java/bin/java -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n -Djava.rmi.server.hostname=10.30.0.17 -Dcatalina.ext.dirs=/usr/share/tomcat5/shared/lib:/usr/share/tomcat5/common/lib -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Djava.endorsed.dirs=/usr/share/tomcat5/common/endorsed -classpath /usr/lib/jvm/java/lib/tools.jar:/usr/share/tomcat5/bin/bootstrap.jar:/usr/share/tomcat5/bin/commons-logging-api.jar:/usr/share/java/mx4j/mx4j-impl.jar:/usr/share/java/mx4j/mx4j-jmx.jar -Dcatalina.base=/usr/share/tomcat5 -Dcatalina.home=/usr/share/tomcat5 -Djava.io.tmpdir=/usr/share/tomcat5/temp org.apache.catalina.startup.Bootstrap start
There is a firewall between my PC and the remote server, but the port is well opened, as I can see these packets with tcpdump on the server:
17:41:17.110977 IP X.X.X.X.57010 > Y.Y.Y.Y.irdmi: S 868833744:868833744(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>
17:41:17.111183 IP Y.Y.Y.Y.irdmi > X.X.X.X.57010: S 3571247457:3571247457(0) ack 868833745 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 7>
17:41:17.112624 IP X.X.X.X.57010 > Y.Y.Y.Y.irdmi: . ack 1 win 256
17:41:19.113216 IP Y.Y.Y.Y.irdmi > X.X.X.X.57010: F 1:1(0) ack 1 win 46
17:41:19.114246 IP X.X.X.X.57010 > Y.Y.Y.Y.irdmi: P 1:15(14) ack 1 win 256
17:41:19.114279 IP Y.Y.Y.Y.irdmi > X.X.X.X.57010: R 3571247458:3571247458(0) win 0
The only message writtent in Tomcat logs is
Debugger failed to attach: timeout during handshake
I can't figure out what's wrong dispite informations I found on the web.
Can anyone can help me?
My server: RHEL 5.9, Tomcat 5.5, java 1.6
Regards,
Robert
I solved my issue : there were a packet inspection activated on the firewall between my PC and the server. It lets certain TCP packets trough, so the TCP handshack can occure, but block data TCP packet.
As I understand, first, a TCP connection is made, then an application handshake is done by the java server with TCP data packet. As data packet was filtered by the firewall, the application handshake could not been completed, and the application close the TCP connection by sending a FIN packet.
Regards,
Robert
Related
First i will tell you my architecture
client--->haproxy--->syslog-ng--->kafka
the client is Cisco ASA and haproxy is server for load-balancing and syslog-ng is for receiving ,filtering and sending logs to kafka(destination)
The client sends logs to haproxy and haproxy send logs to syslog-ng using tcp transport
As in tcp the client-server timeout breaks whenever client restored the connection its PRI value is negative which we seeing in wireshark.With this issue the messages gets mixup
Connection restored is normal but PRI value is negative this is incorrect.
I am showing you the the logs
<-1>May 24 2021 17:40:28: %ASA--1-6414004: TCP Syslog Server private:xx.xx.xx.xx/1470 -
Connection restored\\nCAL\\\\John Mike/xxxxxxxxxxxxxxxxxx) to private:xx.xx.xx.xx/xx duration 0:00:00 bytes 142
(John Mike/xxxxxxxxxxxxxxxxxx)\\nxxxxxxx)\\n4 2021 17:40:28: %ASA-6-302016: Teardown UDP connection 1733810491
we've increase the client connection timeout from 1min to 12 hr but the problem is not resolved
Some version of the Cisco ASA TCP Syslog code are affected by bug CSCvz85683:
Symptom:
Wrong syslog message format, ex for 414004:
-1>Sep 08 2021 10:46:25: %ASA--1-6414004: TCP Syslog Server private:xx.xx.xx.xx/1470 - Connection restored\n (xx.xx.xx.xx/64437)
Conditions:
External logging to TCP server is enabled
Workaround:
NA
Further Problem Description:
ASA syslog messages have 6-digit ID
The valid range for message IDs is between 100000 and 999999.
Source: Cisco ASA Series Syslog Messages. About ASA Syslog Messages.
When logging via TCP on versions with the defect code, will shift the priority (6 in this case) into the message code (414004 in this case) and use an illegal priority -1.
According to the bug, this has been fixed in version 9.14.4.
I recently started using flutter to create an app that has video and audio calling, so I thought of using WebRTC to accomplish this. However, when I tried to create a local WebRTC server from the WebRTC Github it doesn't let me connect to it. When I run the server from the command prompt it tells me that the server is listening at the given local IP, but when I try to connect to it, it says the site can't be reached. Also when I ping the url it says the ping request could not find the host. Any kind of help would really be appreciated.
WebRTC server: https://github.com/flutter-webrtc/flutter-webrtc-server
Starting server in command prompt
netstat when server running
pinging server
The IP 0.0.0.0 is not the IP address the server is binding/listening too.
It is a common way that servers allow configurion 0.0.0.0 to express binding to all IPv4 the host has (see https://en.wikipedia.org/wiki/0.0.0.0 ). To acually reach your server use whatever IP you have on the host (if you are starting the server on your workstation 127.0.0.1 ought to work)
Ping on Windows is only ICMP if I am not mistaken, this means a TCP port number is not part of it's expected input. Eg. "0.0.0.0:8086" is not a valid target for that command (see https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping )
>ping 0.0.0.0:8086
Ping request could not find host 0.0.0.0:8086. Please check the name and try again.
>ping 0.0.0.0
Pinging 0.0.0.0 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
Ping statistics for 0.0.0.0:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
>ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C
Since what you are trying to connect to is a webserver you could use something like curl instead to try to verify your connection. Should be available without any further install if you are on Windows 10 1803 or newer.
>curl https://0.0.0.0:8086
curl: (7) Failed to connect to 0.0.0.0 port 8086: Address not available
>curl https://127.0.0.1:8086
<html><head><title>Unauthorized</title></head><body><h1>401 Unauthorized</h1></body></html>
Some browsers might support https://0.0.0.0:8086 in a similar way server do but I wouldn't rely on it. Go with https://127.0.0.1:8086 or a non localhost IP address of the host.
Environment: HDP 2.6.4
Ambari – 2.6.1
3 zookeeper server
23.1.35.185 - is the IP of the first zookeeper server
hi all,
In the first zookeeper server it seems that even after closing the connection to zookeeper is not getting closed,
which causes the maximum number of client connections to be reached from a host - we have maxClientCnxns as 60 in zookeeper config
As a result when a new application comes and tries to create a connection it fails.
Example when Connections are:
echo stat | nc 23.1.35.185 2181
Latency min/avg/max: 0/71/399
Received: 3031 Sent: 2407
Connections: 67
Outstanding: 622
Zxid: 0x130000004d
Mode: follower
Node count: 3730
But after some time when connection comes to ~70 we see
echo stat | nc 23.1.35.185 2181
Ncat: Connection reset by peer.
And We can see also many CLOSE_WAIT
java 58936 zookeeper 60u IPv6 381963738 0t0 TCP Zookeper_server.sys54.com:eforward->zookeper_server.sys54.com:44983 (CLOSE_WAIT)
From the zookeeper log
2018-12-26 02:50:46,382 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory#193]
- Too many connections from /23.1.35.185 - max is 60
In the ambari we can see also
Connection failed: [Errno 104] Connection reset by peer to zookeper_server.sys54.com.:2181
I must to say that this not happening on zookeeper servers 2 and 3
NOTE - if we increase the maxClientCnxns to 300 , its not help because after some time we get more the 300 connections ( CLOSE_WAIT ) and then we see from the log
2018-12-26 02:50:49,375 [myid:1] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxnFactory#193] - Too many connections from /23.1.35.187 - max is 300
so any hint why the connection are CLOSE_WAIT ?
CLOSE_WAIT means that the local end of the connection has received a FIN from the other end, but the OS is waiting for the program at the local end to actually close its connection.
The problem is your program running on the local machine is not closing the socket. It is not a TCP tuning issue. A connection can (and quite correctly) stay in CLOSE_WAIT forever while the program holds the connection open.
Once the local program closes the socket, the OS can send the FIN to the remote end which transitions you to LAST_ACK while you wait for the ACK of the FIN. Once that is received, the connection is finished and drops from the connection table (if your end is in CLOSE_WAIT you do not end up in the TIME_WAIT state).
There is a kernel level property to reuse the connection and reduce the CLOSE_WAIT time.
I suggest you to follow this tutorial http://www.linuxbrigade.com/reduce-time_wait-socket-connections/
This should probably solve your problem.
I have created an asio server with acceptor:
m_acceptor(m_ios, asio::ip::tcp::endpoint(asio::ip::address_v4::any(), port_num)
where port number is 3333
At this point, the netstat -antup command shows :
13:tcp 0 0 0.0.0.0:3333 0.0.0.0:* LISTEN 26566/./test
So, I believe this means that local address 0 0.0.0.0:3333 is ready to listen to any connection on port 3333
After this, I start the client which creates the endpoint to ip : 127.0.0.1 and port 3333
After this, the netstat output is:
tcp 0 0 0.0.0.0:3333 0.0.0.0:* LISTEN 26566/./test
tcp 0 0 127.0.0.1:3333 127.0.0.1:46675 ESTABLISHED 26566/./test
tcp 0 0 127.0.0.1:46675 127.0.0.1:3333 ESTABLISHED 26685/./test
Process 26566 is master process
Process 26685 is slave process
What I do not understand is what does the the port 46675 mean in the address shown above? This definitely represents the client side, but from where was this port number allocated to the client?
Does this mean that client has connected to port 3333 but the port from which it itself connects is 46675?
Does this mean that client has connected to port 3333 but the port from which it itself connects is 46675?
Basically. It describes the client endpoint. This is BSD/Posix sockets jargon.
What I do not understand is what does the the port 46675 mean in the address shown above? This definitely represents the client side, but from where was this port number allocated to the client?
It gets automatically chosen (by the TCP stack, usually in the kernel) from the local port range. E.g. on linux you can manipulate that range (if you have permission):
sudo sysctl -w net.ipv4.ip_local_port_range="60000 61000"
(Warning: don't do this unless you know what you're doing). See also https://en.wikipedia.org/wiki/Ephemeral_port
I am trying to debug the application on my macbook pro ( os Mountain Lion ). But when I click on debug it is alerting that: unable to connect localhost 4010. I set the port to 4010 on jboss. Here is the output while app starting.
Listening for transport dt_socket at address: 4010
On Jidea; settings for debug is "remote server"
Remote Connection Settings;
host : localhost
port : 4010
Most likely you are using debugger port in place for HTTP port:
In case if you just want to connect to your local application server:
Open "Run/Debug configurations" window.
Add new configuration - Remote
Set up Port to your Jboss socket port