In the NETIF_RECEIVE_SKB () function, you can see that processing is like ARP, IP these link layer above the protocol, then, the link layer header is where to remove it? The answer is in the NIC driver, before calling NETIF_RECEIVE_SKB (),
Skb->protocol = Eth_type_trans (SKB, bp->dev);
The function skips the Ethernet header after processing Skb>data, and the Ethernet header is indicated by Mac_header:
Enter NETIF_RECEIVE_SKB () function
List_for_each_entry_rcu (Ptype,&ptype_base[ntohs (type) & Ptype_hash_mask], list)
According to the protocol type, the Protocol module is processed in order, and the Protocol module processing is registered in the Ptype_base, which is actually a linked list structure.
Net/core/dev.c
static struct List_head ptype_base __read_mostly; * Taps * *
The corresponding protocol module is added through the Dev_add_pack () function:
void Dev_add_pack (struct packet_type *pt)
{
int hash;
SPIN_LOCK_BH (&ptype_lock);
if (Pt->type = = htons (eth_p_all))
List_add_rcu (&pt->list, &ptype_all);
else {
hash = Ntohs (pt->type) & Ptype_hash_mask;
List_add_rcu (&pt->list, &ptype_base[hash]);
SPIN_UNLOCK_BH (&ptype_lock);
}
Take ARP processing as an example
The definition of the module, which is registered in the Ptype_base list in Arp_init ():
static struct
packet_type arp_packet_type __read_mostly = {
. Type = Cpu_to_be16 (eth_p_arp)
. Func = Arp_rcv,
};
Then the actual call to ARP_RCV () is received when the corresponding protocol module is found in Ptype_base according to the type of the message.
ARP_RCV ()--> arp_process ()
ARP = ARP_HDR (SKB);
..... arp_ptr= (unsigned char *) (arp+1);
Sha= arp_ptr;
Arp_ptr + + dev->addr_len;
memcpy (&sip, Arp_ptr, 4);
Arp_ptr + 4;
Arp_ptr + + dev->addr_len;
memcpy (&tip, Arp_ptr, 4);
This pointer position after operation: