Score:0

No SYN-ACK Packet from server

es flag

I have two servers and I used my own embedded system with LwIP to do connection to these server.

My embedded system with LwIP is the client and I have server1 and server2. I connected to server1 and end the connection before connecting to server2.

Further breakdown on the flow:

  1. Client creates New Socket with server1
  2. Client sent DNS packet to obtain server1's ip address; received ACK from AP
  3. Client send TCP SYN packet;
  4. Server1 send TCP SYN-ACK and perform some data transmission
  5. Client ends connection with server1 by sending TCP RST packet; and close socket
  6. Client creates New Socket with server2
  7. Client sent DNS packet to obtain server2's ip address; received ACK from AP
  8. Client send TCP SYN packet to server2
  9. Server2 send TCP SYN-ACK and perform some data transmission
  10. Client ends connection with server2 by sending TCP RST packet; and close socket

However, sometimes server2 did not response to client's SYN Packet which is in Step 9. Its only happens sometime. I checked several forum like:

[1] Why would a server not send a SYN/ACK packet in response to a SYN packet

[2] Server not sending a SYN/ACK packet in response to a SYN packet

My code does not enable window scaling. I cannot check the server as its a private server, so I am not very sure if it was dropped. My environment is quite noisy and busy with many routers plus communication devices. This problem only happens in noisy environment but not in a cleaner environment.

What can I do as a client to fix this problem?

Score:2
ng flag

Somes ideas on why sometimes your server doesn't answer with SYN-ACK :

  • Application on the server is stopped when the SYN packet is sent : This can be a crash and then manage to work again with a auto restart mecanism of the program. When the server app is stopped or crashed, the tcp listening socket is closed, so the OS doesn't answer.
  • You server has some troubles to find your client back. The can be some routing issue or asymetric routing (this break firewall).
  • If the Client and server are on the same network, this can be some issue with Layer 2 issue like Spanning Tree protocol or ARP.
  • Packet loss in the network : You SYN or SYN ACK packet is dropped.
  • The server is overwhelm and sometime cannot answer you SYN packet.

There can be a large number of thing that can make server doesn't answer SYN packet.

What I will do :

  • Doing some tcpdump on the server to verify the network : Does the server receive the SYN packet or there is an issue in the network beforehand ? Does the server generate and send a SYN ACK packet ? And work from there.
  • If you don't have access to the server, doing the same thing on the closest router/firewall.
  • Contact someone that has access on the server.
Sue Koh avatar
es flag
Thank you for the awesome feedback. I will try to get access to the server, if possible. I have another question. Because I am using lwip and apparently I failed to get syn-ack from server, my lwip_connect will stop and doesn't return a value (most probably blocking). Also there is no retry in the SYN packet, any idea why is that so? The port I'm using is 8883 for secure mqtt.
Nicox avatar
ng flag
Unfortunately I don't have any knowledge on "lwip". What I can say though, is that when trying to send a SYN packet and you don't have any answer, the client is supposed to retransmit that SYN packet multiple times before giving up. This seams more like an issue with lwip.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.