socket connect function use 4 handshake?

The first 3 lines of your tcpdump output are the 3-way handshake.

The fourth line is just the server sending out an ACK for some reason. Note that the first line is from port 51188 to port 9877 (client to server SYN), while the second line is from port 9877 to port 51188 (server to client SYN+ACK), the third line is from port 51188 to port 9877 (client to server ACK, ending the 3-way handshake), and the fourth line is from port 9877 to port 51188 (server to client, not a copy of the client to server ACK).

That doesn’t happen with an Ubuntu server; this is probably either a difference between the macOS and Linux TCP implementations or in the SSH daemons being used.

I determined this by running tcpdump on a Linux machine and telnetting to port 22 on a Mac (so the loopback device isn’t involved); the same four packets (3-way handshake plus extra ACK) showed up.

(No, packets sent on the loopback interface aren’t seen twice when capturing traffic on all operating systems. They’re seen twice if you’re capturing traffic on Linux, but libpcap filters out the outgoing copy in its packet reading code. They are not seen twice on macOS – or other BSD-flavored OSes.

The capture mechanisms in Linux and macOS/*BSD are different:

  • Linux uses PF_PACKET sockets, which deliver both incoming and outgoing copies of packets on the loopback interface, but they look identical, with the same source and destination ports, so if libpcap didn’t discard the outgoing copy, you’d see two identical packets, but libpcap discards the outgoing copy, so you see only one;
  • macOS/*BSD/Solaris 11/AIX use BPF devices, which deliver only one copy of packets on the loopback interface, so there’s no copy to discard.)

CLICK HERE to find out more related problems solutions.

Leave a Comment

Your email address will not be published.

Scroll to Top