Process for analyzing data at the bottom layer of the protocol stack

The process for analyzing data at the underlying layer of the Protocol Stack:When the NIC receives data, hardware interruption occurs. The interrupt handler is generally registered with the NIC Driver.) read data from the NIC and encapsulate the sk_buff {} structure, then pass the data to the netif_rx function for further processing.

Function netif_rx) depending on the congestion of the current receiving queue, select discard or receive. If yes, the received sk_buff {} is mounted to the receiving queue softnet_data [CPU]-> input_pkt_queue, and call the function _ cpu_raise_softirq) to activate the Soft Interrupt NET_RX_SOFTIRQ. The corresponding processing function is net_rx_action ).

In the net_rx_action function), call the corresponding processing function based on the protocol type of the data packet. For an IP package, the processing function is ip_rcv ).

Function ip_rcv) performs a series of necessary checks on the IP package, including checking the checksum), and finally calls the function ip_rcv_finish) to transmit the data packets upwards.

Function ip_rcv_finish) First call the function ip_route_input to obtain the route and check whether the packet is sent to the local machine or to be forwarded. If the packet is to be forwarded, call the function ip_forward to forward the packet, otherwise, call the ip_local_deliver function to transfer data packets to the upstream node.

The ip_local_deliver function first filters out the firewall, and finally calls the ip_local_deliver_finish function to transfer data up.

In the ip_local_deliver_finish function), we will check whether there is a matching protocol. If we determine based on the IP header that our data packet is a TCP packet, we need to determine whether there is an original set of interfaces to receive the TCP packet. Of course, it is also possible to have the original set interface that receives all IP packets. If so, call the raw_v4_input function for processing.

In the raw_v4_input function, for further matching, there are four bases for this matching: Protocol, source address, destination address, and receiving interface. Call the raw_rcv function for each matching interface to transmit a cloned data packet in the sk_buff {} structure.

The following functions are simple: The call sequence is raw_rcv), raw_rcv_skb), and sock_queue_rcv_skb ). These functions are basically simple sequential call relationships. Finally, call the sock_queue_rcv_skb function. This function passes through the skb_queue_tail) function to put the data packet sk_buff {} to the end of the receiving queue sk-> receive_queue.

Protocol stack implementation of the original set interface-binding of the original set Interface

Here we will briefly analyze how to bind the original interface to call the function sk-> prot-> bind, in the creation of the original set interface, we provide the sk-> prot of the set interface, that is, the structure variable raw_prot of structproto, from this we can see that and sk-> prot-> bind pointer actually points to function raw_bind ).

In this function, first judge the status of the Set interface. If it is TCP_CLOSE, it will exit. Then some common checks are performed on the parameters. In addition, if you find that the address to be bound is broadcast or multicast, it also exits. If these checks are passed, assign values to the address to be bound to sk-> rcv_saddr and sk-> saddr, that is:

Sk-> rcv_saddr = sk-> saddr = addr-> sin_addr.s_addr

Then it Exits normally.

Note that no operation is performed on the port. Even if the user specifies the port to be bound, the kernel ignores the operation.

Protocol stack implementation of the original set interface-connection of the original set Interface

The structproto structure given in the section on the creation of the original set interface shows that the connection of the original set interface actually calls the udp_connect function, finally, I saw something less "primitive.

In this function, the user's parameters are checked first. Of course, it also checks whether the specified domain is "AF_INET". If not, an EAFNOSUPPORT error is returned.

Then, this function calls the function ip_route_connect) to obtain a route to the destination address. If it fails, an error is returned.

The next work seems a bit hard to understand.

It checks whether the set interface specifies the source address. If not, it assigns the source address of the route to the source address of the Set interface, that is:

If (! Sk-> saddr)

Sk-> saddr = rt-> rt_src;/* Updatesourceaddress */

If (! Sk-> rcv_saddr)

Sk-> rcv_saddr = rt-> rt_src;

Sk represents the sock {} structure of our set of interfaces, rt represents the route we found, and a structrtable {} structure.

Finally, the target address and port are assigned to the specified field of the Set interface, and the status of the Set interface is updated at the same time, that is:

Sk-> daddr = rt-> rt_dst;

Sk-> dport = usin-> sin_port;

Sk-> state = TCP_ESTABLISHED;

Protocol stack implementation of the original set interface-Closing of the original set Interface

Based on the above experience, the original interface should call the function raw_close). This function simply calls the function ip_ra_control), in the function ip_ra_control, delete this interface from the linked list ip_ra_chain and release it to all the space occupied by this interface.

Application of the original set Interface

Based on the previous analysis, we can draw the following conclusions for the application of the original interface.

Binding Problems

You can call the bind function for the original interface, but it is not commonly used. This function is only used to set the local address. For an original set of interfaces, the port number is meaningless. When outputting data, bind sets the source IP address to be used in the datagram sent on the original interface only when the IP_HDRINCL interface option is not set); If bind is not called, the kernel sets the source IP address to the primary IP address of the outbound interface.

Connection problems

You can call the connect function on the original interface, but it is not commonly used. The connect function only sets the destination address. Re-apply: the port number is meaningless for the original interface. For the output, we can call write or send instead of sendto because the destination address has been specified after connect is called.

Output Problems

1)Normal output is usually completed through sendto or sendmsg and the destination IP address is specified. If the set of interfaces are connected, you can also call write, writev, or send.

2)If the IP_HDRINCL option is not set, the start address of the data written by the kernel is the first byte after the IP header. In this case, the kernel constructs an IP header and installs it before the data from the process. The kernel sets the protocol field in the IPv4 header to the third parameter that the user gives when calling the socket function.

3)If the IP_HDRINCL option is set, the data written by the kernel is actually the first byte in the IP header. The data provided by the user must include the IP header. In this case, the process constructs the entire IP header except the following two items:

(1)The IPv4 field can be set to 0, and the kernel needs to set this value. The kernel is set only when this field is set to 0.

(2)The IPv4 header checksum is calculated and stored by the kernel.

4)If the protocol type is specified when the original set interface is created, that is, the third parameter protocol, it does not mean that only data packets of this type can be sent. For example, even if you specify protocol as IPPROTO_TCP, you can also send user-assembled UDP packets. However, if the IP_HDRINCL option is not set, then, the kernel will specify the following packet as a TCP packet in the protocol field of the IP header, but it is a UDP packet at this time ). The packet is sent to the peer TCP layer. Generally, the packet is discarded because the appropriate TCP interface cannot be found to receive the packet. However, this package can be received on the original interface of the target host.

5)As mentioned above, the IP header checksum is set by the kernel at any time.

6)At any time, the kernel does not perform verification on fields after the IP package. For example, even if we specify the third parameter protocol as IPPROTO_TCP, the kernel does not perform TCP checksum calculation and verification during data transmission.

7)If the IP_HDRINCL option has been set, we should set up our own IP Address Header, but even if we do not set up an IP address header, you can still use sendto or sendmsg and specify the destination IP address to send data. However, such a packet cannot be received using the original interface on the target machine, because the IP header needs to be verified in ip_rcv and the checksum needs to be analyzed, so the packet will be discarded, however, this packet should be received at the link layer.

8)If the IP_HDRINCL option is set and the data packet length is too long, the data is discarded and the error code EMSGSIZE is returned. If the IP_HDRINCL option is not set and the packet length is too long, the packet will be split.

Input Problems

1)The original interface can receive any TCP or UDP packets.

2)To receive the original set of interfaces, the first packet to be received must have a complete and correct IP header. Otherwise, the packet header in ip_rcv cannot be checked and verified.

3)During the packet received by the original interface, the kernel verifies and verifies the received IP packet, but does not detect and verify any fields in the IP packet. For example, when we create the original set of interfaces, the specified protocol parameter is IPPROTO_TCP, and the kernel does not perform TCP checksum verification, instead, copy all the packets whose protocol field is TCP in the IP header and submit them to the original interface.

4)The TCP packets received by the original interface are all packets before TCP sorting after IP address reorganization.

5)If the specified protocol parameter is not zero when the original interface is created, and the third parameter of the socket is used), the protocol field of the received datagram should match. Otherwise, the datagram is not transmitted to this interface.

6)If a local IP address is bound to the original interface, the destination IP address of the received datagram should match the bound IP address. Otherwise, the packet will not be transmitted to the interface.

7)If the original packet interface specifies an IP address of the other Party through connect, the source IP address of the received packet should match the connection address; otherwise, the packet is not transmitted to the interface.

8)If an original set of interfaces is created using the protocol parameter 0 and connect or bind is not called, for each original datagram transmitted by the kernel to the original set of interfaces, this interface will receive a copy.

9)The original interface does not receive any ARP or RARP interface, because net_rx_action ()

Packets of the ARP or RARP protocol are transmitted to the receiving function class of ARP, but not to the receiving function ip_rcv of the IP layer ).

10)The original set interface does not receive any ICMP data packets, because some ICMP data packets have been responded by the system before being passed to the original set interface, and are no longer transmitted to the upper layer.

11)If the packets of the other party are sliced, the original IP packet will be received after the reorganization because the original interface is received at the IP layer.

Edit recommendations]