Debian 7: connection problems and timeouts - linux

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.

Related

how to enable wsl to respond to broadcast ping request

I was using WSL to run ROS commands, and at a point i had to enable system to respond to broadcast icmp requests (for a multi master kind of a setup) i.e. on linux i had to make sure
cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
returns 0. but WSL does not contain such a file, so i was thinking of enabling it on windows. All the sources i have gone through suggest me to add a rule to firewall but my system is not responding to broadcast ping even when my system's firewall is turned off(domain, private and public have been turned off same with my buddy who is no the same network). i am using an android phone's mobile hotspot to check this.
it would be great if someone could help me on this.
thanks in advance.
I asked something similar
I don't know how to do it purely on WSL. But on windows you have to start the "TCPSVCS.EXE" process. located on System32

PYMODBUS: How to get master to communicate with slave?

I'm working on a project where I have two Debian VMs that both have Pymodbus installed. I'm trying to setup a virtual testing environment where I can perform various cyber attacks on the two from a third Kali VM while they communicate. Unfortunately, I'm very new to unix and PLC programming, and am having some difficulty getting the two to communicate with each other. Ideally, the master should send data to the slave, who then updates some information and sends a response back. Does anyone know how to begin to get these two to work together? I'm really at a loss here, and I have no idea where to begin. Thank you so much, I really appreciate it.
I got pymodbus from here: https://pypi.python.org/pypi/pymodbus
Documentation located here: https://github.com/riptideio/pymodbus
P.S. I used pip to install the above .whl file, but I've seen other people install pymodbus by simply running a command, which makes me worry that I've done this all wrong.
You can run a test in one Debian VM system.
1. run the server file, and set the ip and port.
2. run the client file, and connect to the ip and port.
That is tcp/ip method and you can do serial method by the same file.Just look the comments in the above files. If any questions, let me know.
server picture:
client picture:
updated:
1.connect two PCs by local area network.Make sure two PCs can ping each other.
2.set synchronous-server.py:
StartTcpServer(context, identity=identity, address=("0.0.0.0", 5020))
which means listen all the coming connection requests from all ip.
3.setsynchronous-client.py(let's assume the server pc ip is "192.168.1.10", you should replace this ip to real server ip):
client = ModbusClient('192.168.1.10', port=5020)
4.run the two py files and it should works now.

Traceroute: target doesn't acknowledge packet just from a specific host. Traceroutes from other hosts work fine. Ping works fine from all hosts

So I am a bit puzzled by this. All of this is in a larger corporate network, but all machines are basically on site.
We have one machine (linux) sending SOAP requests to the other machine (windows) and since a few days these requests fail after a certain time. We haven't found any pattern as to which requests fail (doesn't seem to be a particular request).
We tried a traceroute from the requesting machine to the target machine and the target machine doesn't acknowledge the packet (asterisks at the target). A running ping did work and did not drop any packets.
The target machine is a VM on a host hosting many machines.
The problem started after a scheduled restart a few days ago.
Our team is actually only responsible for the application on the target server, but we are invested in helping pinpoint the problem.
Apart from running wireshark on the target server and looking for the traceroute or soap packets, is there any other point of failure where we can investigate?
If you are using domain names (not IP), check that they are resolved properly. ISP dropping the packets would not be an issue since everything is on site.
Ping works, so I assume both machines see each other on the network. But is it should be the sending machine (linux) to send the Ping to be sure that the machine isn't blocked somewhere in the network.
Ping works, but traceroute doesn't, check for possible Firewall issues. Check if its the request not getting to the Windows machine or the reply isn't getting out.

oracle thin jdbc connection receiving "connection reset" after inactivity

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

andlinux slirp network failed

I have installed andlinux Beta 2 on my WinXP. Everything works fine until last night, I don't recall that I ever changed anything on network configuration or andlinux setup, the network stop working inside andlinux. With that said, I mean open a KDE console, I do "ping yahoo.com", I see DNS is resolved correctly, however, no response at all.
My andlinux is startup as a WinXP service. Open windows task manager I can see following services are up and running:colinux-daemon.exe colinux-net-daemon.exe colinux-slirp-net-daemon.exe
On andlinux side, there are two network interface eth0 and eth1. eth1 is configured to communicate with local WinXP. I configured it to use samba to access windows directories, no problem. From WinXP side, I can use ssh to login into andlinux box via eth1 IP address.
eth0 is configured as slirp, no port forwarding. eth0 has IP=10.0.2.15, default gateway is 10.0.2.2, netmask=255.255.255.0; These are configured in /etc/network/interfaces. DNS is 10.0.2.3, which as I just mentioned resolve yahoo.com correctly.
On the windows side, internet works fine. I disabled firewall on all network interface. I rebooted my laptop, no luck. I searched over inet, seem no one has this problem. People say network is done if they kill the colinux-slirp-net-daemon. What frustrated me is that this whole thing worked well, but for no reason it's broken all the sudden. Anyone has experience on this issue, please help, appreciate!
I thought I had the same problem, but then found my andLinux system's network connectivity was actually working fine, and that several things made it difficult to tell what was going on.
Test I did to validate connectivity: wget www.yahoo.com
Behavior I observed that made troubleshooting difficult:
Pings from andLinux - not all hosts will respond to pings from the andLinux OS (ie Ubuntu, not the Host Windows OS). According to my packet captures the pings appear as UDP pings instead of ICMP pings once they leave the host OS's adapter. The major IPs/hosts (like yahoo, google, 4.2.2.2 etc.) on the internet I usually ping to test connectivity currently don't respond to these type of pings.
Traceroutes from andLinux - even when successful, these never show more than 2 hops when done from the andLinux OS. If successful, both hops show 10.0.2.2. If unsuccessful, the second hop just times out. Not sure why, I'm sure there is an explanation.
Packet captures - at the host OS level, the capture (eg wireshark) must be done on the physical interface the traffic is going over. I was initially capturing on the TAP-Win32 Adapter but this only showed X Window traffic.
Installed apt sources URLs no longer valid - Ubuntu 9.04 is long out of support by now, so the URLs in the apt sources.list file didn't exist anymore. This is what got me thrown off in the first place, because I didn't troubleshoot this specifically and just tried to test my internet connectivity first, then got confused by the ping and traceroute behavior seen above. Changed http://us.archive.ubuntu.com/ubuntu to http://old-releases.ubuntu.com/ubuntu/ in sources.list and was good to go.

Resources