We have experienced an issue with a CORBA server. A client host connected to this server was sending some CORBA commands that did not get any response from the server. when we took a tcpdump (it is a Linux machine), we saw the following:
client sent SYN
server replied with SYN,ACK
client then sent ACK
server sent again and again (3 times) the SYN,ACK and eventually after three * attempts it sent RST.
Does anyone know why this happened? Why would syn, ack be sent after client ACK?
Related
When using the -T option to use TCP SYN for probes, (1.)is this how it works: SYN is sent and ACK is received so only a two way handshake occurs so connection with server is made but no confirmation is sent back to server? and it still tracks the server address and data received through traceroute,(2.) is this what keeps the probes from being identified by server firewall/ applications?
I have an iOS chat app talking to a java XMPP chat server via TCP socket. The server machine(machine 1) was running redhat linux. Recently I moved the chat server to another Linux machine(machine 2) with similar configuration except that it had more processors. The way the server works is that once it receives a particular data from client(data1) then it sends 2 xml packets to the client(data2 and data3). Looking at the packets in wireshark, I see the below
the consistent behavior in machine1.
iOS App Java server
SYN -->
<-- SYN,ACK
ACK -->
TCP handshake ends here
data1 -->
<-- ACK
<-- data2
ACK -->
<-- data3
ACK -->
But in machine2 it works like below.(not always but most of the time)
iOS App Java server
SYN -->
<-- SYN,ACK
ACK -->
TCP handshake ends here
data1 -->
<-- ACK
<-- data2
<-- data3
ACK -->
ACK -->
As seen above the ACK for 2 packets are sent all at once by the client.
Why is there such a change in behavior. Since the app is the same in both the cases what could have made the server send data 3 without receiving ACK for data2. I have verified most of the TCP socket related properties in these machines like send buffer , TCO_NODELAY etc. but all these looks the same. What can I do if the need the behavior as it was in the machine1.
I ve also noticed that this behavior is mainly seen when I connect through wifi.
I'm attempting to craft a raw TCP packet to send over Ether in a raw socket on a linux client and server. The special part of the TCP packet is that I'm attempting to use the raw data field of the TCP SYN packet and RST packet to send data back and forth (for a proof of concept about an unused part of the TCP protocol).
I've disabled RST packets from my iptables on the server.
In short, here's my current situation:
Client sends SYN with data is sent to server
Server receives a SYN packet without data
Server responds with a RST packet with data
Client receives a RST packet without data
But, using the same socket, I can successfully do this:
SYN without data sent to server
Server receives a SYN packet
Server responds with a SYN ACK packet with data
Client receives a SYN ACK packet without data
Client receives a PSH ACK packet with data
Can someone explain to me why the packets I send don't seem to make it to the server in the same way I send them?
Why am I receiving two packets (one with SYN ACK and one with PSH ACK) in my successful attempts?
SYN and RST packets seem to lose their data, but SYN ACK packets don't. Is this a firewall issue?
If so, how can I debug what's intercepting my packets?
Thanks!
Turns out the VMWare virtual adapter was modifying the packets in transit. When I did a packet capture on the host operating system, there were no issues transmitting data.
Is there any way to delay the Syn-ACK when the SYN is send by the client to the server and server has reply with SYN-ACK, in the three-way handshake protocol, is there any specific tuning required in sysctl.cnf file or whether it can be done by iptables settings ?
Heres the scenrio:
TCP server running on solaris, TCP client running on Linux. Client connects and starts sending data. Client stops sending data and after N inactive seconds the server send a FIN, ACK (presumably from a shutdown call on the send pipe). The client starts sending data again. The server freaks out and starts sending a bunch of RST packets with no other flags set. The first packet is lost and they handshake again. The send never returns an error and the one packet is silently lost.
Any ideas why the RST is not being propagated to the client?
The send error and re-connect is being propgated. My bad. Staring at logs too long I guess. THANKS!