How the data is passed in the router

For the average person, as long as you can use a router to surf the internet, but for a qualified network management, it is necessary to know the router's work process, especially to know how the data is passed in the router.

When the data passes through the router, the Connect function can be called on the original set interface, and the Connect function only sets the destination address. Again: The port number has no meaning for the original set of interfaces. For output, after calling connect, we can call write or send instead of sendto because the destination address is already specified.

Second, the normal output usually through sendto or sendmsg and specify the destination IP address to complete, if the socket is already connected, you can call write, Writev or send, if the IP_HDRINCL option is not set, The data start address that the kernel writes is the first byte after the IP header.

Because in this case, the kernel constructs the IP header and then it is put in front of the process data. The kernel sets the Protocol field for the IPV4 header to the third parameter that the user gives when calling the socket function.

Third, if the IP_HDRINCL option is set, the kernel writes the data in fact the address is the first byte of the IP header. The data provided by the user must include the IP header. At this point, the process constructs an entire IP header other than the following two items, and the IPv4 label field can be set to 0, requiring the kernel to set the value. And only if the field is 0 o'clock, the kernel is set and IPV4 header checksum is computed and stored by the kernel.

If you specify a protocol type when you create the original socket, that is, the third parameter protocol, that is not to say that you can only send packets of that type. For example, even if the protocol designated as IPPROTO_TCP, you can send the user to assemble the UDP message, but if the IP_HDRINCL option is not set, then the kernel will be in the IP header of the Protocol field indicates that the following message is TCP (but at this time is a UDP message).

Packets are sent to the other TCP layer and are generally discarded because the appropriate TCP socket interface is not found to receive the packet. However, the package can be received on the target host's original set of interfaces.

If the IP_HDRINCL option has been set, according to the general, should build their own IP headers, but even if we do not build IP headers, with sendto or sendmsg and specify the destination IP address to send the data is still possible to complete. However, such packets are not received on the target machine with the original set of interfaces, because the IP header is validated in IP_RCV () and the checksum is parsed, so the packet is discarded, but it should be able to receive the packet at the link layer.

Vi. If the IP_HDRINCL option is set and the packet is too long, the data is discarded and an error code emsgsize is returned. If the IP_HDRINCL option is not set and the packet is too long, the packet is fragmented and the packet must be received in a complete, correct IP header to receive the original socket, otherwise it cannot be checked and validated by the header in Ip_rcv ().

In the packet process received by the original set of interfaces, the kernel verifies and validates the IP packets received, but does not detect and verify any subsequent fields in the IP packet. For example, when we create the original socket, the specified protocol parameter is ipproto_tcp, and the kernel does not perform TCP checksum verification, but instead copies the protocol field in the IP header to all packets of TCP, and submits it to the original set interface.

Eight, the original set of interfaces received by the TCP packets are IP reorganization after the TCP sorting the previous message. If the specified protocol parameter is not zero when the original socket is created, (the third parameter of the socket), the Protocol field of the datagram received should match.

Otherwise, the datagram is not passed to the set of interfaces. If a local IP address is bound to the original socket, the destination IP address of the received datagram should match the IP address of the binding, otherwise the packet will not be passed to the socket interface.

If the original set interface specifies an offset IP address through connect, the packet's source IP address should match the connection address, otherwise the packet is not passed to the socket.

The original set of interfaces could not receive any set of ARP or RARP protocol types, because Net_rx_action () would pass the ARP or RARP protocol type packets to the ARP receiving function class and would not pass to the IP layer's receive function IP_RCV (), Because some ICMP-type packets are already being responded to by the system before being passed to the original socket interface, they are no longer passed upward.