I am trying to understand what are linux services/process involved in making tcp 3-way handshake. for example who send reject flag [R.] for SYN request.

example: port 8088 is listening and 8089 is open. tcpdump output below after making a connection request on both the ports.

for 8089:

$ sudo tcpdump -i any -nn port 8088 or port 8089
04:23:12.260621 IP > Flags [S], seq 300539809, win 43690, options [mss 65495,sackOK,TS val 19840756 ecr 0,nop,wscale 7], length 0
04:23:12.260637 IP > Flags [R.], seq 0, ack 300539810, win 0, length 0

for 8088:

$ sudo tcpdump -i any -nn port 8088 or port 8089
04:23:21.680070 IP > Flags [S], seq 670408355, win 43690, options [mss 65495,sackOK,TS val 19850176 ecr 0,nop,wscale 7], length 0
04:23:21.680087 IP > Flags [S.], seq 1185731197, ack 670408356, win 43690, options [mss 65495,sackOK,TS val 19850176 ecr 19850176,nop,wscale 7], length 0
04:23:21.680098 IP > Flags [.], ack 1, win 342, options [nop,nop,TS val 19850176 ecr 19850176], length 0

so here which linux service sending sending [R.] for 8089 and [S.] SYN-ACK for 8088? also how the packet reach listener, what is the flow? what will be the flow when firewall rule is added (using iptables) to drop packet on 8089?

thanks in advance :)

  • 3
    Do you simply want to know which process is using a port (in which case, search for lsof, netstat or ss)? Or are you specifically interested in what's going on at the TCP/IP/ethernet levels, in the Linux kernel?
    – JigglyNaga
    Commented Feb 13, 2020 at 10:37

1 Answer 1


Flags in TCP packets aren't managed by services and processes directly.

Usually, developers use standard POSIX interfaces to develop network functionnalites: socket(), connect(), listen(), bind(), accept(), etc...

The Linux kernel is the main recipient for these calls, it:

  • Allocates ressource to the service (when calling socket() for example) and, if ressource is already in use (ex: bind()-ing an already used address/port couple), it returns error appropriate error to the calling process.

  • Manages the real TCP stack stuff aka the 3-way handshake when developper calls connect(), or returning a RST if no service is binded to the requested address/port couple (or if service reject the connection)

  • receive the packets from the outside and forward its content to the appropriate process (the one which has done the bind() or connect() to/from the address/port and is actually calling recv() or read() on the related socket.

Note that, prior to coming to the processes, the firewall is triggered to ensure that the network stream is allowed. So, even if you have a service listening on TCP/8000, if your firewall doesn't allow connection to it, then you'll get:

  • A RST if the iptables policy or rules do a REJECT.
  • A timeout if the iptables policy or rules do a IGNORE.
  • thanks @binarym. is there any specific kernel process who is the recipient of all these calls? i know some of the c libraries like libpcap for packet capturing. is that kernel process using some similar libraries. Commented Feb 13, 2020 at 18:15
  • Note the file-wall, and routing etc is done by nftables inside the kernel. There is also a user-mode nftables for configuring nftables. Formally it was iptables/ip6tables/arptables/ebtables etc. nftables is much more simple and more powerful. Commented Feb 13, 2020 at 18:43
  • If you want to understand how the kernel deals with network packets, I highly recommend this presentation by Jiri Benc. Commented Feb 14, 2020 at 9:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .