17.11. MAC 地址解析 · Linux 設備驅動 (第三版)

## 17.11.?MAC 地址解析以太網通訊的一個有趣的方面是如何將 MAC 地址( 接口的唯一硬件 ID )和 IP 編號結合起來. 大部分協議有類似的問題, 但我們這里集中于類以太網的情況. 我們試圖提供這個問題的完整描述, 因此我們展示三個情形: ARP, 無 ARP 的以太網頭部( 例如 plip), 以及非以太網頭部. ### 17.11.1.?以太網使用 ARP 處理地址解析的通常方法是使用 Address Resolution Protocol (ARP). 幸運的是, ARP 由內核來管理, 并且一個以太網接口不需要做特別的事情來支持 ARP. 只要 dev->addr 和 dev->addr_len 在 open 時正確的賦值了, 驅動就不需要擔心解決 IP 編號對應于 MAC 地址; ether_setup 安排正確的設備方法給 dev->hard_header 和 dev_rebuild_header. 盡管通常內核處理地址解析的細節(并且緩存結果), 它需要接口驅動來幫助建立報文. 畢竟, 驅動知道物理層頭部細節, 然而網絡代碼的作者已經試圖隔離內核其他部分. 為此, 內核調用驅動的 hard_header 方法使用 ARP 查詢的結果來布置報文. 正常地, 以太網驅動編寫者不需要知道這個過程 -- 公共的以太網代碼負責了所有事情. ### 17.11.2.?不考慮 ARP 簡單的點對點網絡接口, 例如 plip, 可能從使用以太網頭部中受益, 而避免來回發送 ARP 報文的開銷. snull 中的例子代碼也屬于這一類的網絡設備. snull 不能使用 ARP 因為驅動改變發送報文中的 IP 地址, ARP 報文也交換 IP 地址. 盡管我們可能輕易實現了一個簡單 ARP 應答發生器, 更多的是演示性的來展示如何直接處理網絡層頭部. 如果你的設備想使用通常的硬件頭而不運行 ARP, 你需要重寫缺省的 dev->hard_header 方法. 這是 snull 的實現, 作為一個非常短的函數: ~~~ 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); } ~~~ 這個函數僅僅用內核提供的信息并把它格式成標準以太網頭. 它也翻轉目的以太網地址的 1 位, 理由下面敘述. 當接口收到一個報文, eth_type_trans 以幾種方法來使用硬件頭部. 我們已經在 snull_rx 看到這個調用. ~~~ skb->protocol = eth_type_trans(skb, dev); ~~~ 這個函數抽取協議標識( ETH_P_IP, 在這個情況下 )從以太網頭; 它也賦值 skb->mac.raw, 從報文 data (使用 skb_pull)去掉硬件頭部, 并且設置 skb->pkt_type. 最后一項在 skb 分配是缺省為 PACKET_HOST(指示報文是發向這個主機的), eth_type_trans 改變它來反映以太網目的地址: 如果這個地址不匹配接收它的接口地址, pkt_type 成員被設為 PACKET_OTHERHOST. 結果, 除非接口處于混雜模式或者內核打開了報文轉發, netif_rx 丟棄任何類型為 PACKET_OTHERHOST 的報文. 因為這樣, snull_header 小心地使目的硬件地址匹配接收接口. 如果你的接口是點對點連接, 你不會想收到不希望的多播報文. 為避免這個問題, 記住, 第一個字節的最低位(LSB)為 0 的目的地址是方向一個單個主機(即, 要么 PACKET_HOST, 要么 PACKET_OTHERHOST). plip 驅動使用 0xfc 作為它的硬件地址的第一個字節, 而 snull 使用 0x00. 兩個地址都導致一個工作中的類似以太網的點對點連接. ### 17.11.3.?非以太網頭部我們剛剛看過硬件頭部除目的地址外包含了一些信息, 最重要的是通訊協議. 我們現在描述硬件頭部如何用來封裝相關的信息. 如果你需要知道細節, 你可從內核源碼里抽取它們或者從特定傳送媒介的技術文檔中. 大部分驅動編寫者能夠忽略這個討論只是使用以太網實現. 值得一提的是不是所有信息都由每個協議提供. 一個點對點連接例如 plip 或者 snull 可能在不失去通用性的情況下避免傳送這個以太網頭部. hard_header 設備方法, 由 snull_header 實現所展示的, 接收自內核的遞交的信息( 協議級別和硬件地址 ). 它也在 type 參數中接收 16 位協議編號; IP, 例如, 標識為 ETH_P_IP. 驅動應該正確遞交報文數據和協議編號給接收主機. 一個點對點連接可能它的硬件頭部的地址, 只傳送協議編號, 因為保證遞交是獨立于源和目的地址的. 一個只有 IP 的連接甚至可能不發送任何硬件頭部. 當報文在連接的另一端被收到, 接收函數應當正確設置成員 skb->protocol, skb->pkt_type, 和 skb->mac.raw. skb->mac.raw 是一個字符指針, 由在高層的網絡代碼(例如, net/ipv4/arp.c)所實現的地址解析機制使用. 它必須指向一個匹配 dev->type 的機器地址. 設備類型的可能的值在 <linux/if_arp.h> 中定義; 以太網接口使用 ARPHRD_ETHER. 例如, 這是 eth_type_trans 如何處理收到的報文的以太網頭: ~~~ skb->mac.raw = skb->data; skb_pull(skb, dev->hard_header_len); ~~~ 在最簡單的情況下( 一個沒有頭的點對點連接 ), skb->mac.raw 可指向一個靜態緩存, 包含接口的硬件地址, protocol 可設置為 ETH_P_IP, 并且 packet_type 可讓它是缺省的值 PACKET_HOST. 因為每個硬件類型是獨特的, 給出超出已經討論的特別的設備是困難的. 內核中滿是例子, 但是. 例如, 可查看 AppleTalk 驅動( drivers/net/appletalk/cops.c), 紅外驅動(例如, driver/net/irds/smc_ircc.c), 或者 PPP 驅動( drivers/net/ppp_generic.c).