I have a new tomcat application server running on tomcat 6, java 6 (openjdk), centos 6.2. The server is a virtual machine running under qemu-kvm on a centos 6.2 host. Both host and guest are 64-bit.
I have a case where a connection is opened, (from a connection pool) then a "long computation" occurs for about 4 hours, during which the connection is not used. Finally, a "commit" is issued, and the server gives a "connection reset" exception, specifically:
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:185)
at oracle.net.ns.Packet.receive(Packet.java:282)
at oracle.net.ns.DataPacket.receive(DataPacket.java:103)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:230)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:175)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:100)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:85)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:122)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:78)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1179)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1155)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:279)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
at oracle.jdbc.driver.T4C7Ocommoncall.doOCOMMIT(T4C7Ocommoncall.java:75)
at oracle.jdbc.driver.T4CConnection.doCommit(T4CConnection.java:558)
The database server and the client are on the same subnet, except the server is a real physical host, and obviously the app-server is a guest running inside a physical machine on the same subnet.
The host used "bridged" networking.
This may not be a software problem at all but rather a linux os configuration (iptables?) issue, but I really don't know.
I have run into this a couple of times. Almost always caused by a network timeout (load balancer or firewall). But you have clearly mentioned that your servers are on the same subnet, so not really sure what is going on. Since you suspect iptables, can you turn it off, run the test and see if it works (too easy huh :)
Regardless, assuming you are connecting to an Oracle db, the following tweak helps
http://raibledesigns.com/rd/entry/tomcat_oracle_connectivity_problems
If you use a different db (say mysql) the setting might be different but the logic is the same. Setup a keepalive value to prevent the connection from being idle for too long. This way the firewal/load balancer/iptables software will not terminate it.
As you can see in this post in Oracle Forums, this can have more than one problem / solution.
Check if your JDBC driver version is correct
Check your ORACLE_HOME environment variable
try add the argument -Djava.security.egd=file:///dev/urandom
Your logic use a singleton to get the connection? In the post this are mentioned too
Hope this helps you.
#user is referring to a good workaround, by configuring "SQLNET.EXPIRE_TIME=10" in sqlnet.ora.
However, this workaround is only applicable if your application is using thick OCI (jdbc:oci), not thin (jdbc:thin) driver.
Linux has software firewall, i.e. iptables, which can drop idle network connection, so even you are in the same subnet, you have iptables software firewall. This is activated by default in all modern Linux, and up to Linux administrator to disable it.
By default, Linux iptables does not drop idle TCP/IP connections (jdbc belongs to TCP/IP protocol), so the Linux administrator must configured iptables to do so. Following is the detail explanation for any reader who are interested to know more:
http://www.digitage.co.uk/digitage/software/linux-security/cutter
Business users, security team, or architect often suggest network/OS admin to abort idle connection using firewall, as well as router. This is always a "recommendation" in the anti-hacking community, but it is not properly discussed, and causing application instability. Eventually, you should discuss with the team to find a balance
Related
I want to install Damn Vulnerable Web Application (DVWA) on VirtualBox, so I downloaded the DVWA.iso and I'm following this tutorial for its installation.
At step 9, they say to choose internal network, but I don't really understand why (is it a security problem if I don't choose this option?). Because if I select internal network after I've got an IP like 10.0.something and when I try to connect from my computer (not the VM) to 10.0.something/login.php that doesn't work. But if I select bridge networking, I've got an IP like 192.168.something and it works.
Could you explain me why is it important to choose internal network, and why that doesn't work when I choose this?
Internal network on VirtualBox creates a network between boxes on the same host . I can't see the next steps of the tutorial you linked but my guess is that it will ask you to install Kali (or similar distro) on another box on that same host. This is what most people do.
Setting 'internal network' allows the 2 machines to talk to each other without any contact with the outside.
It is considered a security measure because the DVWA is a vulnerable machine so some people think that you shouldn't be giving access to internet to it, but I guess it's more about 'best practice' than a real security risk because in most cases firewalls, routers and ISP will prevent outside attackers to connect directly to that machine in any case.
Anyways, if you are using another computer on the same network to connect to DVWA you should be ok in using a 'bridged' connection on VirtualBox (this it will give to the DVWA an IP sitting on the same network of the host and of your computer). In NAT mode VirtualBox acts like a router, it may still be a good solution for you but not sure if the box is reachable from other computers as I think VB settings may affect this case.
If you are using instead the Host as a penetration testing machine, 'host only' should be good to allow the host and the VM to talk.
Try to put both of the machines on the NAT so that you can ping onto the dvwa from wherever you're doing the hacking from! so essentially both of the machines should be on NAT setting if the they're both on a virtual machine.
I'm working on cloud, customer need our virtual switch to keep its VM's TCP based connection while our virtual switch upgrading (which is stop virtual switch first and then start new virtual switch). We use ovs, in this case, port of VM will link down and link up in 1 second. Customer's OS is linux.
So I'm thinking if this link down/up will cause the TCP connection broken in VM? I have no idea which part of code in TCPIP stack I should read, as boss tells me I have to show him code other than some blog.
TCP/IP is expressly designed to survive such outages. If your boss insists on seeing code, you will have to show him the entire Linux IP stack, and much good may it do him. More probably you should just refer him to RFC 791 and 793.
On my root server, debian 7 is the operation system. Running kernel is 2.6.32.
I have the problem, that TCP/IP-connections seems to be "unstable".
ssh connections often hang or timeout. Webserver sometimes runs fast, sometimes the client (browser) is waiting and waiting for a response.
I dont know where to start right now for this problems. I made a hardware check requests at my ISP ticket system.
Is there a hint you can give me?
I would guess it is DNS related. I would isolate one destination to communicate to, and one location to communicate from. Using ping, I would determine if there was latency in the link itself (ping from the server to one destination and from your client workstation to the troubled server). Once you determine that times are predictable (no **'s)I would learn both IP addresses and put them in /etc/hosts.
When you run ssh I would consider using -vv to see what it is doing and maybe that will help.
The problem was a broken network adapter in the mainframe of the cluster. The provided fixed the issue.
I accidently broke my centos VM in azure by twiddling firewall rules within it. After a reboot, the normal ssh access is not working anymore. Is there any chance to get into that VM, any console login directly to the machine somehow?
After reading the current state (April 2016) at microsoft about this, I've decided to dump the virtual machine and set it up again:
This one-directional access is just a start. Console screenshots and serial output can help identify a problem, but they are not the solution for resolving the problems. We are working on enhancements that will enable secure bi-directional access to the console of the virtual machine. This will enable additionally debugging capabilities, and, more importantly, the ability to resolve a set of common problems through the bi-directional access. Right now, I don’t have a timeline but we know this is critical.
(article)
I am connecting to virtual machine (ubuntu 14.04) hosted on Microsoft Azure using ssh. My problem is that my connection drops every couple minutes (same period) and I need to reconnect. This is not related to internet connection because it doesn't drop. I tried logging from different pc's, it's all the same.
Sometimes this is caused by inactivity: see http://www.cyberciti.biz/tips/open-ssh-server-connection-drops-out-after-few-or-n-minutes-of-inactivity.html
To summarize, an ssh connection is sometimes dropped after a few minutes.
From the OpenSSH man page:
This is usually the result of a packet filter or NAT device timing out your TCP connection due to inactivity. For security, reason most enterprises only use SSH protocol version 2. This problem only occurred with version 2.
You can try following the instructions in that article.