-2

Why PUSH packets have always ACK flag set? Why not just PUSH?

After 3 way handshake, the very first packet sent by the client should have only PUSH. Where does this ACK comes from?

19:14:58.013699 IP 10.201.98.71.59454 > 10.201.208.15.ssh: Flags [S], seq 1794644890, win 29200, options [mss 1460,sackOK,TS val 18876032 ecr 0,nop,wscale 7], length 0 19:14:58.014613 IP 10.201.208.15.ssh > 10.201.98.71.59454: Flags [S.], seq 176446139, ack 1794644891, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0 19:14:58.014651 IP 10.201.98.71.59454 > 10.201.208.15.ssh: Flags [.], ack 1, win 229, length 0

19:14:58.019507 IP 10.201.208.15.ssh > 10.201.98.71.59454: Flags [P.], seq 1:391, ack 1, win 229, length 390

19:14:58.019541 IP 10.201.98.71.59454 > 10.201.208.15.ssh: Flags [.], ack 391, win 237, length 0

0

For TCP to work correctly, each packet must be acknowledged. If the ACK was missing, eventually the retransmit timer on the other siede would time out and the packet would be resent. In your tcpdump, the fourth packet's ACK lets the other side know, that the third packet of your tcpdump was received. "ACK 1" lets the other side know "I'm waiting for #1, everything before was received".

With or without PUSH flag, you should always see ACKs, as long as packets are sent to and fro. Not sending ACK means "I have not seen a new packet from you since I sent my last packet to you".

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.