| The previous section of this chapter described the path of a packet between a network adapter and the interface to higher protocol instances. This section discusses this interface in more detail. First, we will explain how new protocols can be added. Because only protocols of the network layer (IP, ARP, IPv6, IPX) are added to the Linux network architecture over this interface, it is also referred to as the interface to the network layer or layer-3 protocols in the following discussion. In the Linux kernel, we distinguish between two types of layer-3 protocols, where the first type is used mostly for analysis purposes: A protocol receives all packets arriving at the interface to the layer-3 protocols. A protocol receives only packets with the correct protocol identifier (e.g., 0x0800 for the Internet Protocol).
Figure 6-5 shows that these two types of protocols are managed in two different data structures. We can see in this figure that the two types of layer-3 protocols do not differ much. Both types are managed in a structure of the type packet_type and linked in different lists, depending on the above-mentioned type. The simple linked list, ptype_all, stores the protocols that should receive all incoming socket buffers. The hash table, ptype_base, manages all normal layer-3 protocols. Figure 6-5. Managing protocols above network devices. 
A packet_type structure is created and placed into the corresponding data structure for each protocol. The following parameters are required in the packet_type structure to define a protocol: type: This field specifies the protocol identifier (i.e., the constants listed in Figure 6-6). If ETH_P_ALL is stated in this field, then the protocol is added to the list ptype_all when it is registered, and it receives all packets. Otherwise, it receives only packets with protocol identifier type. The identifier of a protocol has to be extracted from the packet data in the receive routine of the network driver (e.g., by the method eth_type_trans(), which will be introduced at the end of this chapter). dev can take a pointer to a network device. In that case, only the packets received on that network device are passed to the protocol. If several, but not all, network adapters should have this preference, then the protocol for each network device has to be registered separately. If dev contains a NULL pointer, which corresponds to the normal case, then the input network device does not play any role in selecting a protocol. func() is the handling routine for the protocol. This means that this is the point where the protocol's work begins. For example, the handling routine ip_rcv() is registered in the packet_type structure of the Internet Protocol. (See Chapter 14.) data can be used to point to private data of the protocol, but it is generally not used. next is used to link several packet_type structures.
Figure 6-6. Identifiers for layer-3 protocols on the LLC layer (include/Linux/if_ether.h). /* These are the defined Ethernet Protocol ID's. */ ETH_P_LOOP 0x0060 /* Ethernet Loopback packet */ ETH_P_IP 0x0800 /* Internet Protocol packet */ ETH_P_X25 0x0805 /* CCITT X.25 */ ETH_P_ARP 0x0806 /* Address Resolution packet */ ... ETH_P_IPX 0x8137 /* IPX over DIX */ ETH_P_IPV6 0x86DD /* IPv6 */ /* Non DIX types. Won't clash for 1500 types. */ ETH_P_802_3 0x0001 /* Dummy type for 802.3 frames */ ETH_P_AX25 0x0002 /* Dummy protocol id for AX.25 */ ETH_P_ALL 0x0003 /* Every packet (be careful ! ! !) */ ETH_P_802_2 0x0004 /* 802.2 frames */ ETH_P_SNAP 0x0005 /* Internal only */ ...
The following two methods are available to manage the protocols or their packet_type structures: dev_add_pack() | net/core/dev.c |
dev_add_pack(pt) registers with the Linux network architecture the layer-3 protocol represented by the packet_type structure pt. If the field type has the value ETH_P_ALL, then the protocol is added to the list ptype_all. Otherwise, it is inserted in the appropriate row of the hash table ptype_base. From now on, all received packets with protocol identifier type are delivered to this protocol instance.[2] [2] provided that the protocol type is not ETH_P_ALL and the protocol was not registered for one single special network device.
dev_remove_pack() | net/core/dev.c |
dev_remove_pack(pt) removes the protocol with the packet_type structure pt. Depending on the identifier in the type field, it is removed from the corresponding data structure. 6.3.1 Logical Link Control Determining the Layer-3 Protocol Identifier eth_type_trans() | net/ethernet/eth.c |
eth_type_trans(skb, dev) is the second important part of the Logical Link Control (LLC) implementation in the Linux kernel, in addition to managing the networklayer protocols described in Section 6.3. Two important tasks are executed for this purpose: Recognize the LLC protocol type used and the protocol identifier of the layer-3 protocol from the protocol control information contained in the layer-2 data frame. Identify the packet type (unicast, multicast, broadcast) and check on whether the packet is addressed to the local computer.
The method eth_type_trans(), which can be used for all Ethernet-compatible network adapters, is called by the network driver in the packet-receive method. (See Section 5.3.) It is responsible for extracting protocol-control information of the LLC layer and handling it appropriately. For this reason, all network devices of a MAC protocol type use the same type_trans() method. There are similar methods for token ring and FDDI devices (tr_type_trans(), fddi_type_trans()). In general, Ethernet networks do not use any of the LLC standards, but transmit the layer-3 protocol identifier directly in the MAC frame. The only protocol mechanism is thus demultiplexing of different layer-3 protocols. This is the reason why eth_type_trans() is relatively simple and easy to understand. However, you can use an LLC protocol based on IEEE 802.2. First, skb_pull(skb, dev->hard_header_length) takes the layer-2 packet header from eth_type_trans(). Next, the type of the packet is identified and registered in skb->pkt_type. The following mutually exclusive types are possible: PACKET_BROADCAST: The packet was sent to the broadcast address of the local network and is intended for all connected computers. PACKET_MULTICAST: The packet was sent to a layer-2 group address, which means that it is intended for a group of computers. PACKET_HOST: The packet is intended for the local computer (i.e., it was sent to the layer-2 address of the receiving network adapter). PACKET_OTHERHOST: The packet is not intended for the local computer and was received only because the computer is in promiscuous mode.
Subsequently, the protocol identifier of the incoming packet is recognized. In local networks based on the IEEE 802 standard, there are several options, but this book considers only Ethernet-compatible networks: If a value in the length or protocol field of the Ethernet packet header is bigger than the maximum frame length (1536 bytes), then it is assumed that it is an 802.3-compatible Ethernet adapter. As mentioned earlier, the 802.3 protocol integrates the protocol-control information of the LLC layer in the protocol field of the 802.3 frame, thus sparing any need for a separate LLC packet header. This means that the field value contains the protocol identifier of the layer-3 protocol and is registered in skb->type. Older Ethernet adapters store the length of the frame rather than the protocol identifier of the layer-3 protocol in the length or protocol field. For this reason, the protocol-control information of the LLC layer has to be contained in the payload of the Ethernet frame (i.e., an explicit LLC packet header based on the 802.2 standard, SSAP and DSAP see Figure 6-7).
Figure 6-7. Variants for LLC protocol control information in Ethernet networks. 
eth_type_trans() does not verify the LLC-PDU any further, but returns ETH_P_802_2 as the layer-3 protocol identifier. The 802.2 LLC protocol instance is treated as a layer-3 protocol instance. (See Section 6.3.) It is also registered as a layer-3 protocol instance in the hash table ptype_base. Though this conflicts with the layer model, it allows a simpler implementation in this case, because most Ethernet adapters use the integrated LLC variant mentioned previously, and 802.2 is rather an exceptional case. Finally, the demultiplexing process to the layer-3 protocol takes place in the handling routine of the 802.2 protocol (p8022_rcv(), net/802/p8022.c). Layer-3 protocols can register themselves with the 802.2 protocol instance by use of the method register_8022_client(). For example, the SNAP protocol extension (net/802/psnap.c) can register itself with register_8022_client(0xAA, snap_rcv). From then on, the method snap_rcv(), which links to the corresponding layer-3 protocol, is invoked for all SNAP frames. Figure 6-7 shows a summary of the frame formats used for different LLC variants in Ethernet: 802.3: LLC-PCI, integrated in the MAC-PCI. 802.2: LLC-PDU in the MAC payload. 802.2/SNAP: SNAP extension in the LLC-PDU.
|
