which linux service manage packets after they land to ethernet

Question

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 192.168.112.129.52298 > 192.168.112.129.8089: 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 192.168.112.129.8089 > 192.168.112.129.52298: 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 192.168.112.129.42814 > 192.168.112.129.8088: 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 192.168.112.129.8088 > 192.168.112.129.42814: 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 192.168.112.129.42814 > 192.168.112.129.8088: 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 :)

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.