Tag Info

New answers tagged

0

No, I believe this is expected. option http-server-close Will close the connection from HAProxy to the backend, but will keep the connection alive between the client and the haproxy-server. HAProxy will close the connection if/when the timeout is hit, so you might want to tweak the timeout http-keep-alive and timeout client options.


0

I know this question is almost two years old, but it has no answers, so I thought I'd chime in with a way to handle this. This is actually something that works with UDP only because it is stateless, and will not work with TCP. Your described setup with a TCP connection to a third "control" server is actually the perfect setup for this. We'll call the ...


0

I provided the answer in the update of question.


0

Are you missing part of this TCP conversation in your packet capture? The client is sending Acknowledgements and the ACK value is increasing, meaning data has been received from the other end, but there is no such data in your capture. If the remote end sent a FIN but still had some data in its send buffer, or data which had been sent then delayed and ...


1

In a word, no. When you restart the service, you must kill the process which holds the socket file descriptors open. Assuming these are TCP sessions, that means the TCP session must finish (FIN) and a new session be established (SYN) after the service has restarted and a new process is listening on a socket again. Why do you need to restart the service? ...


1

I don't know enough about Windows socket cycling to answer this, but I am guessing the server closes connections and sockets are sitting in TIME_WAIT state where they cannot be used again until they expire. The "right" way to solve this problem is to add more tuples - increase outgoing ports on the client (which you have done), add listening ports on the ...


2

There's been some great info here by @Pat and @Kyle. Definitely pay attention to @Kyle's explanation of the TCP receive and send windows, I think there has been some confusion around that. To confuse matters further, iperf uses the term "TCP window" with the -w setting which is kind of an ambiguous term with regards to the receive, send, or overall sliding ...


2

Another way to do this is to use SLP (Service Location Protocol). There is an open implementation here which supports most major platforms. http://www.openslp.org/ SLP or protocols like it or derived from it are how printers and such things get discovered on networks. The DNS method is certainly the simplest. But there is no announcement that the server ...


0

Make sure bind-address is set to 0.0.0.0, then make sure app armor is giving MySQL networking privileges. Check MySQL and app armor (dmesg I think) logs to see if app armor is blocking network connections.


0

This will most likely by a firewall issue. in your proftpd config limit the ports it will use PassivePorts 61000 61199 That'll limit passive ports to 61000 to 61199. Now ensure that those ports are open in your firewall. There's a great write up about it here


7

Clarifying the Problem: TCP has two windows: The receive window: How many bytes are left in the buffer. This is flow control imposed by the receiver. You can see the size of the receive window in the wireshark since it is made up of the window size and windowing scaling factor inside the TCP header. Both sides of the TCP connection will advertise their ...


9

Have you tried enabling Compound TCP (CTCP) in your Windows 7/8 clients. Please read: Increasing Sender-Side Performance for High-BDP Transmission http://technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx ... These algorithms work well for small BDPs and smaller receive window sizes. However, when you have a TCP connection with a large ...


2

A SYN received on an ESTABLISHED TCP connection should not be happening. It could be a delayed packet, which it would be safe to silently drop. It is possible to end up with the server in ESTABLISHED state and client in CLOSED state if the connection is lost and is timed out on the client and not on the server, or if the client is restarted. Attempting to ...


0

Neither...SYN is only used when the connection is first set up (the three-way handshake) or when the packet is destroyed. Basically: SYN (I want to start a connection) -> ACK/SYN (OK, I want to start a connection too) -> ACK (acknowledged connection, ready for data) Conversation flows with ACK packets sent by both hosts indicated they recieved each ...


0

If you mount with vers=3,proto=tcp, TCP is used when querying rpcbind for the actual mount: $ tshark -nr nfs.pcap "tcp.stream eq 0" 2 192.168.1.89 36200 192.168.1.60 111 TCP 74 [SYN] 3 192.168.1.60 111 192.168.1.89 36200 TCP 74 [SYN, ACK] 4 192.168.1.89 36200 192.168.1.60 111 TCP 66 [ACK] 5 192.168.1.89 36200 192.168.1.60 111 Portmap 126 V2 ...


11

Surely you have python? from socket import * from struct import unpack import sys INTERFACE = "eth0" TARGET = "8.8.8.8" if __name__ == "__main__": sock = socket(AF_PACKET, SOCK_DGRAM, 0x0800) sock.bind((INTERFACE, 0x0800)) while True: data = sock.recvfrom(1500, 0)[0] ip = inet_ntop(AF_INET, data[12:16]) if ip == TARGET: ...


5

Kyle offered some great options. One more would be to use iptables: [james@server ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32 ... [james@server ~]$ sudo iptables -L OUTPUT -n -v Chain OUTPUT (policy ACCEPT 105 packets, 35602 bytes) pkts bytes target prot opt in out source destination 87 33484 LOG all -- * * 0.0.0.0/0 1.2.3.4 LOG ...


14

Iptables has a debug capability and that can be used for traffic analysis too. The solution is described on the URL below. Debugging rules in Iptables It's also worth reading the following URL to set up the logging of trace output to a file of your choice. http://backreference.org/2010/06/11/iptables-debugging/ I would not consider this solution equal ...


11

I'd really try to get tcpdump. That being said, some alternatives to see if a certain connection exists for an IP are: strace: [kbrandt@ny-kbrandt01: ~] strace -e trace=network nc 1.2.3.4 1234 ... socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("1.2.3.4")}, 16) = -1 EINPROGRESS ...


8

If you need specific software to do your job, and aren't allowed to, you're either not making a good business case or selling your ideas to the right people... or you're not in control of this system... If I were tasked to do something and needed the type of debugging/troubleshooting information that you require in this case, I'd use the right tool. That's ...


0

LAST_ACK means your end has received a FIN from the peer, sent an ACK, sent a FIN, and is waiting for the final ACK from the peer. At this point there is nothing further the application can do: the socket is closed. The application may even have exited. From here on it is up to TCP to resend the FIN until it gets the final ACK, or time out doing so. Not ...


0

Most likely there are firewall rules in router_2 that prevent SSH access from the IP address space used by the routed mode tunnel Check the firewall in router_2.


3

After configuring AMT to listen on a shared IP address, I ran the test mentioned by kasperd in the comments above. (against my own remote host with an SSH server, not actually example.com, of course) Here is the result: Positive test case (using a port not used by AMT): $ nc -p 16991 example.com 22 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4 ^C $ Negative ...


1

We had the same issue but for a different protocol. While using IOS version 8.x (cannot remember the exact release), there was an issue with the Inspects that would mess up the order in wich it would relay the packets. Do you have HTTP/HTTPS inspects enabled? If so, you can create an ACL and "exclude" one or two machines from the inspects just for them ...


4

You can set the ServerAliveInterval and ServerAliveCountMax settings on the client. The maximum time before the client will disconnect is approximately the product of those two.


1

The IP addresses to use for the TCP connection are chosen by the client when the connection is established. The choice can be made either by the application layer by binding the socket to a specific IP before connecting, or by the kernel if the application layer did not make a choice. The choice made by the kernel can be controlled in a few different ways. ...


5

They disconnect. TCP has no protocol part for changing the IP address so the clients will not know that it has changed magically. A new connection will have to be established.



Top 50 recent answers are included