17.11. MAC 地址解析

17.11.?MAC 地址解析

以太網(wǎng)通訊的一個有趣的方面是如何將 MAC 地址( 接口的唯一硬件 ID )和 IP 編號結(jié)合起來. 大部分協(xié)議有類似的問題, 但我們這里集中于類以太網(wǎng)的情況. 我們試圖提供這個問題的完整描述, 因此我們展示三個情形: ARP, 無 ARP 的以太網(wǎng)頭部( 例如 plip), 以及非以太網(wǎng)頭部.

17.11.1.?以太網(wǎng)使用 ARP

處理地址解析的通常方法是使用 Address Resolution Protocol (ARP). 幸運的是, ARP 由內(nèi)核來管理, 并且一個以太網(wǎng)接口不需要做特別的事情來支持 ARP. 只要 dev->addr 和 dev->addr_len 在 open 時正確的賦值了, 驅(qū)動就不需要擔心解決 IP 編號對應于 MAC 地址; ether_setup 安排正確的設備方法給 dev->hard_header 和 dev_rebuild_header.

盡管通常內(nèi)核處理地址解析的細節(jié)(并且緩存結(jié)果), 它需要接口驅(qū)動來幫助建立報文. 畢竟, 驅(qū)動知道物理層頭部細節(jié), 然而網(wǎng)絡代碼的作者已經(jīng)試圖隔離內(nèi)核其他部分. 為此, 內(nèi)核調(diào)用驅(qū)動的 hard_header 方法使用 ARP 查詢的結(jié)果來布置報文. 正常地, 以太網(wǎng)驅(qū)動編寫者不需要知道這個過程 -- 公共的以太網(wǎng)代碼負責了所有事情.

17.11.2.?不考慮 ARP

簡單的點對點網(wǎng)絡接口, 例如 plip, 可能從使用以太網(wǎng)頭部中受益, 而避免來回發(fā)送 ARP 報文的開銷. snull 中的例子代碼也屬于這一類的網(wǎng)絡設備. snull 不能使用 ARP 因為驅(qū)動改變發(fā)送報文中的 IP 地址, ARP 報文也交換 IP 地址. 盡管我們可能輕易實現(xiàn)了一個簡單 ARP 應答發(fā)生器, 更多的是演示性的來展示如何直接處理網(wǎng)絡層頭部.

如果你的設備想使用通常的硬件頭而不運行 ARP, 你需要重寫缺省的 dev->hard_header 方法. 這是 snull 的實現(xiàn), 作為一個非常短的函數(shù):

int snull_header(struct sk_buff *skb, struct net_device *dev,
                 unsigned short type, void *daddr, void *saddr,
                 unsigned int len)
{
    struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN);
    eth->h_proto = htons(type);
    memcpy(eth->h_source, saddr ? saddr : dev->dev_addr, dev->addr_len);
    memcpy(eth->h_dest,  daddr ? daddr : dev->dev_addr, dev->addr_len);
    eth->h_dest[ETH_ALEN-1]  ^= 0x01;  /* dest is us xor 1 */
    return (dev->hard_header_len);
}

這個函數(shù)僅僅用內(nèi)核提供的信息并把它格式成標準以太網(wǎng)頭. 它也翻轉(zhuǎn)目的以太網(wǎng)地址的 1 位, 理由下面敘述.

當接口收到一個報文, eth_type_trans 以幾種方法來使用硬件頭部. 我們已經(jīng)在 snull_rx 看到這個調(diào)用.

skb->protocol = eth_type_trans(skb, dev);

這個函數(shù)抽取協(xié)議標識( ETH_P_IP, 在這個情況下 )從以太網(wǎng)頭; 它也賦值 skb->mac.raw, 從報文 data (使用 skb_pull)去掉硬件頭部, 并且設置 skb->pkt_type. 最后一項在 skb 分配是缺省為 PACKET_HOST(指示報文是發(fā)向這個主機的), eth_type_trans 改變它來反映以太網(wǎng)目的地址: 如果這個地址不匹配接收它的接口地址, pkt_type 成員被設為 PACKET_OTHERHOST. 結(jié)果, 除非接口處于混雜模式或者內(nèi)核打開了報文轉(zhuǎn)發(fā), netif_rx 丟棄任何類型為 PACKET_OTHERHOST 的報文. 因為這樣, snull_header 小心地使目的硬件地址匹配接收接口.

如果你的接口是點對點連接, 你不會想收到不希望的多播報文. 為避免這個問題, 記住, 第一個字節(jié)的最低位(LSB)為 0 的目的地址是方向一個單個主機(即, 要么 PACKET_HOST, 要么 PACKET_OTHERHOST). plip 驅(qū)動使用 0xfc 作為它的硬件地址的第一個字節(jié), 而 snull 使用 0x00. 兩個地址都導致一個工作中的類似以太網(wǎng)的點對點連接.

17.11.3.?非以太網(wǎng)頭部

我們剛剛看過硬件頭部除目的地址外包含了一些信息, 最重要的是通訊協(xié)議. 我們現(xiàn)在描述硬件頭部如何用來封裝相關的信息. 如果你需要知道細節(jié), 你可從內(nèi)核源碼里抽取它們或者從特定傳送媒介的技術文檔中. 大部分驅(qū)動編寫者能夠忽略這個討論只是使用以太網(wǎng)實現(xiàn).

值得一提的是不是所有信息都由每個協(xié)議提供. 一個點對點連接例如 plip 或者 snull 可能在不失去通用性的情況下避免傳送這個以太網(wǎng)頭部. hard_header 設備方法, 由 snull_header 實現(xiàn)所展示的, 接收自內(nèi)核的遞交的信息( 協(xié)議級別和硬件地址 ). 它也在 type 參數(shù)中接收 16 位協(xié)議編號; IP, 例如, 標識為 ETH_P_IP. 驅(qū)動應該正確遞交報文數(shù)據(jù)和協(xié)議編號給接收主機. 一個點對點連接可能它的硬件頭部的地址, 只傳送協(xié)議編號, 因為保證遞交是獨立于源和目的地址的. 一個只有 IP 的連接甚至可能不發(fā)送任何硬件頭部.

當報文在連接的另一端被收到, 接收函數(shù)應當正確設置成員 skb->protocol, skb->pkt_type, 和 skb->mac.raw.

skb->mac.raw 是一個字符指針, 由在高層的網(wǎng)絡代碼(例如, net/ipv4/arp.c)所實現(xiàn)的地址解析機制使用. 它必須指向一個匹配 dev->type 的機器地址. 設備類型的可能的值在 <linux/if_arp.h> 中定義; 以太網(wǎng)接口使用 ARPHRD_ETHER. 例如, 這是 eth_type_trans 如何處理收到的報文的以太網(wǎng)頭:

skb->mac.raw = skb->data;
skb_pull(skb, dev->hard_header_len);

在最簡單的情況下( 一個沒有頭的點對點連接 ), skb->mac.raw 可指向一個靜態(tài)緩存, 包含接口的硬件地址, protocol 可設置為 ETH_P_IP, 并且 packet_type 可讓它是缺省的值 PACKET_HOST.

因為每個硬件類型是獨特的, 給出超出已經(jīng)討論的特別的設備是困難的. 內(nèi)核中滿是例子, 但是. 例如, 可查看 AppleTalk 驅(qū)動( drivers/net/appletalk/cops.c), 紅外驅(qū)動(例如, driver/net/irds/smc_ircc.c), 或者 PPP 驅(qū)動( drivers/net/ppp_generic.c).