At boot time, the network drivers are built into the kernel and initialized. This results in a series of device data structures linked together in the dev_base list.Each device data structure describes its device and provides a set of callback routines that the network protocol layers call when they need the network driver to perform work.These functions are mostly concerned with transmitting data and with the network device's addresses.When a network device receives packets from its network it must convert the received data into sk_buff data structures. These received sk_buff's are added onto the backlog queue by the network drivers as they are received.If the backlog queue grows too large, then the received sk_buff's are discarded. The network bottom half is flagged as ready to run as there is work to do.
When the network bottom half handler is run by the scheduler it processes any network packets waiting to be transmitted before processing the backlog queue of sk_buff's determining which protocol layer to pass the received packets to.As the Linux networking layers were initialized, each protocol registered itself by adding a packet_type (include/linux/netdevice.h) data structure onto either the ptype_all list or into the ptype_base hash table.The packet_type data structure contains the protocol type, a pointer to a network device, a pointer to the protocol's receive data processing routine and, finally, a pointer to the next packet_type data structure in the list or hash chain. The ptype_all chain is used to snoop all packets being received from any network device and is not normally used.The ptype_base hash table is hashed by protocol identifier and is used to decide which protocol should receive the incoming network packet. The network bottom half matches the protocol types of incoming sk_buff's against one or more of the packet type entries in either table. The protocol may match more than one entry, for example when snooping all network traffic, and in this case the sk_buff will be cloned.The sk_buff is passed to the matching protocol's handling routine. For example, IP packets are passed onto ip_rcv.
Packets are transmitted by applications exchanging data or else they are generated by the network protocols as they support established connections or connections being established. Whichever way the data is generated, an sk_buff is built to contain the data and various headers are added by the protocol layers as it passes through them.
The sk_buff needs to be passed to a network device to be transmitted.First though the protocol, for example IP, needs to decide which network device to use.This depends on the best route for the packet.For computers connected by modem to a single network, say via the PPP protocol, the routing choice is easy.The packet should either be sent to the local host via the loopback device or to the gateway at the end of the PPP modem connection. For computers connected to an Ethernet the choices are harder as there are many computers connected to the network. For every IP packet transmitted. IP uses the routing tables to resolve the route for the destination IP address. Each IP destination successfully looked up in the routing tables returns a rtable data structure describing the route to use.This includes the source IP address to use, the address of the network device data structure and, sometimes, a prebuilt hardware header. This hardware header is network device specific and contains the source and destination physical addresses and other media specific information. If the network device is an ethernet device, the hardware header would be as shown in Figure [*] and the source and destination addresses would be physical ethernet addresses. The hardware header is cached with the route because it must be appended to each IP packet transmitted on this route and constructing it takes time. The hardware header may contain physical addresses that have to be resolved using the ARP protocol. In this case the outgoing packet is stalled until the address has been resolved.Once it has been resolved and the hardware header built. the hardware header is cached so that future IP packets sent using this interface do not have to ARP.
The packets that are from a source and to a destination other than this machine are forwarded to the next hop machine provided that this machine is configured to be an ip_forwarder and there is a valid routing table entry for the destination machine. This machine will act as a router. The ip_forwarding can be controlled via a configuration parameter or a sysctl variable using the proc system interface. The function ip_rcv checks if a particular packet is for the machine itself. If yes, it will provide the packet to the appropriate upper level protocol's receive handler. If this is not the case, and the ip_forwarding is enabled, it will call the ip_forward routine. The ip_forward routine will consult the routing table to find the next hop for this destination and transmits the packet to that machine. But, before this, it might have to masquerade the packet and it is explained shortly.