基于嵌入式終端的DHCP網(wǎng)絡接入及接入認證的研究與實現(xiàn)

摘要：DHCP協(xié)議是為TCP/IP網(wǎng)絡分配網(wǎng)絡參數(shù)而設計的應用層協(xié)議，它能在局域網(wǎng)內為終端動態(tài)分配IP地址。首先，對DHCP協(xié)議進行了研究分析，尤其是它的網(wǎng)絡連接和續(xù)約的協(xié)商過程；其次，基于上述的協(xié)商過程，重要的是在基于Linux的嵌入式終端設備中如何實現(xiàn)，本文介紹了詳細的實現(xiàn)過程；第三，互聯(lián)網(wǎng)電視終端設備的可管理、可運營對運營商來說是非常重要的，本文還討論了基于DHCP網(wǎng)絡接入的認證；最后，將實現(xiàn)上述需求的代碼交叉編譯后下載到IPTV終端并調試成功，通過分析截取的網(wǎng)絡包，結果證明成功地實現(xiàn)了IPTV終端基于DHCP的網(wǎng)絡接入及接入認證。

關鍵詞：IPTV；DHCP協(xié)議；OPTION60認證；DHCP租約；嵌入式系統(tǒng)

中圖分類號：TP393.08 文獻標識碼：A 文章編號：1007-9599 （2012） 23-0000-02

1 引言

DHCP（Dynamic Host Configuration Protocol）源于BOOTP，BOOTP原本用于無磁盤主機連接到網(wǎng)絡，但BOOTP的缺點是須先獲得客戶端的物理地址且與IP地址的對應是靜態(tài)的，即缺乏\"動態(tài)性\"，造成IP資源的極大浪費。而DHCP（RFC-1541）則是一種動態(tài)主機配置協(xié)議，可分為服務器端和客戶端兩個部份，它提供一系列IP參數(shù)配置對用戶端進行配置。通過終端上的DHCP客戶端，利用自動發(fā)現(xiàn)機制來嘗試聯(lián)接網(wǎng)絡中的DHCP服務器。DHCP協(xié)議本身沒有認證功能，但DHCP可以配合其它技術實現(xiàn)認證網(wǎng)絡主機。隨著業(yè)務的多樣化，用戶認證方式作為可運營、可管理的核心，受到包括運營商、制造商的密切關注。如DHCP+OPTION認證的方式在IPTV等類似終端上得到了廣泛的應用。

2 基于DHCP協(xié)議的需求分析

基于DHCP+接入認證的方式在諸如IPTV等業(yè)務方面有廣泛的應用。按用戶的要求和運營商的模式，本文重點分析了IP地址的自動分配和續(xù)約。DHCP分為客戶端和服務器端兩個部分，客戶端啟動之后以廣播的方式發(fā)送discover報文請求，DHCP服務器以單播的形式發(fā)送offer回應。如果網(wǎng)絡中有多個DHCP服務器，終端可能會收到多個DHCP回應，但只擇其一；接著客戶端以DHCP方式發(fā)送request請求，DHCP服務器以單播的形式發(fā)送ack回應，給客戶終端分配一個IP地址。客戶端收到IP后，以廣播的方式發(fā)送arp，檢查分配到的地址是否被使用。如果該IP未被使用，則地址分配成功。如果該IP地址已被使用，則發(fā)送decline請求拒絕，然后重新廣播發(fā)送discover請求。DHCP開始會發(fā)送兩次discover請求，間隔8秒。

自動獲得的地址只能保持一段時間，因此DHCP需要續(xù)約。過程大致如下：（1）終端將在T1（租期的50%）時間發(fā)起第一次續(xù)約請求（Request報文），如在T1時間發(fā)送的請求未收到回復時，需在T1.5（租期的68.75%）再發(fā)送一次重試請求（Request報文），2次報文發(fā)送方式為單播；（2）終端如果在第一次續(xù)約（T1和T1.5）時沒有得到回應的ACK報文后，將在T2（租期的87.5%）第二次發(fā)送續(xù)約請求（Request報文），如在T2時間發(fā)送的請求未收到回復時，需在T2.5（租期的93.75%）時間再發(fā)起一次重試請求（Request報文），2次報文發(fā)送方式為廣播；（3）如果4次續(xù)約仍然沒有回應。將在租約到期后清除地址，重新發(fā)送兩次Discover包。也就是說極端情況下會發(fā)送四次request續(xù)約請求。其中任何一次過程得到ack回應，就不再繼續(xù)后續(xù)流程。若四次續(xù)約請求失敗，則將在租約到期后清除地址，再發(fā)送discover廣播。

3 基于Linux的DHCP協(xié)議業(yè)務流程的實現(xiàn)

把上面所定義的DHCP需求嵌入到網(wǎng)絡終端。網(wǎng)絡終端采用Linux操作系統(tǒng)，整個DHCP協(xié)議的實現(xiàn)也依賴于Linux的網(wǎng)絡控制腳本rc.ethernet。其中rc.ethernet業(yè)務流程主要分rc.ethernet start、rc.ethernet stop、rc.ethernet restart三部分。

3.1 啟動DHCP。通過rc.ethernet start，檢查系統(tǒng)網(wǎng)絡設置，加載網(wǎng)卡驅動，啟動dhcpcd將終端接入網(wǎng)絡。大致過程如下：（1）檢查配置文件/mnt/nv/rc.alt_eth是否存在，打開debug信息顯示；（2）宏定義腳本中要使用的命令；（3）找出網(wǎng)絡終端使用的網(wǎng)卡驅動模塊；（4）檢查是否設定包序；（5）加載網(wǎng)卡驅動；（6）開始執(zhí)行rc.dhcp腳本；（7）檢查是否存在DHCP的cache文件；（8）如果DHCP能夠獲取到IP地址，則不再執(zhí)行獲取IP操作；（9）如果支持IGMP，則建立IGMP。

3.2 DHCP初始化階段。DHCP初始化階段的主要操作有：（1）初始化各個參數(shù)；（2）檢查argv[]，根據(jù)不同的值進行相關的操作；（3）指定當前使用的接口，這里默認為eth0；（4）指定當前程序的名字，這里為dhcpcd；（5）指定當前程序運行的環(huán)境變量；（6）檢查是否指定了dns參數(shù)，如果是，則配置dns option；（7）打開syslog日志記錄，創(chuàng)建syslog日志存放的文件目錄；（8）建立信號集；（9）指定bootp message中的magic_cookie、DHCP信息內容大小、租期時間；（10）檢查運行模式，在前臺執(zhí)行或是后臺執(zhí)行，進入releaseDHCPOptions（）函數(shù)，釋放DHCP option中的值；進入DHCP sendandrecv_init（）函數(shù)，構建DHCP discover包并發(fā)送。

3.3 租期階段

3.3.1 成功獲取IP地址。獲得IP過程的實現(xiàn)如下：進入DHCP sendandrecv_init （）函數(shù)；構建DHCP discover數(shù)據(jù)包并發(fā)送；根據(jù)發(fā)包后是否有回應包，決定進入哪個函數(shù)。

實現(xiàn)成功獲取IP地址的機制如下：（1）構建DHCP discover包并發(fā)送，如果有回應，則進入parseDHCPMsgRecv （）函數(shù)，接受DHCP server發(fā)來的包，如果參數(shù)-f開啟，檢測DHCP option 125中的值；（2）檢測DHCP server發(fā)來的包中是否存在DHCPServerIdentifier、檢測dns、檢測subnetMask、檢測broadcastAddr、檢測DHCPIPaddrLeaseTime、檢測DHCPT1value、檢測DHCPT2value、檢測DHCPMessageType；（3）構建DHCPRequest包并發(fā)送；（4）進入parseDHCPMsgRecv （）函數(shù)，接受DHCP server發(fā)來的包，如果參數(shù)-f開啟，檢測DHCP option 125中的值；（5）檢測DHCP server發(fā)來的包中是否存在DHCPServerIdentifier，檢測dns、檢測subnetMask、檢測broadcastAddr、檢測DHCPIPaddrLeaseTime、檢測DHCPT1value、檢測DHCPT2value、檢測DHCPMessageType；（6）通過arpcheck，驗證收到的DHCP包中指派的IP地址是否被占用。如果沒被占用，進入DHCP config函數(shù)，配置IP地址、子網(wǎng)掩碼、廣播地址、靜態(tài)路由；（7）清除DHCP server address、DHCP server file。

3.3.2 獲取IP失敗。兩種情況下會出現(xiàn)獲取IP失敗。一種情況是發(fā)送DHCP discover無回應，則相應的處理機制如下：（1）構建DHCP discover包并發(fā)送；（2）如果沒有回應，則進入DHCPRelease（）函數(shù)，刪除DHCP cache文件；進入DHCPstop（）函數(shù)，釋放DHCP option選項中的值；（3）關閉socket。另一種情況是arp地址檢測沖突，則相應的處理機制如下：（1）通過arp check，驗證收到的DHCP包中指派的IP地址是否被占用；（2）如果被占用，進入DHCPdecline函數(shù)；（3）構建DHCPDecline message包并發(fā)送；（4）進入DHCPdecline函數(shù)。

4 接入認證的研究與實現(xiàn)

為了解決對用戶進行有效的接入認證控制問題和提高接入網(wǎng)絡的安全性，DHCP+接入認證技術在網(wǎng)絡安全、網(wǎng)絡監(jiān)控以及用戶控制和終端識別等方面對DHCP協(xié)議進行了擴展。本文采用DHCP+OPTION 60進行認證。其中OPTION60中帶有Vendor和Service Option信息，是由用戶終端發(fā)起DHCP請求時攜帶的信息，網(wǎng)絡設備只需要透傳即可。其在應用中的作用是用來識別用戶終端類型，從而識別用戶業(yè)務類型，DHCP服務器可以依賴于此分配不同的業(yè)務IP地址。也就是在客戶端輸入用戶名和密碼的方式進行地址鑒權，讓server識別client。

4.1 OPTION60的實現(xiàn)過程

具體的實現(xiàn)過程如下：（1）在Client啟動后，如果FLASH中沒有儲存用戶名和密碼信息，則馬上彈出要求輸入用戶名與密碼的窗口由用戶輸入用戶名和密碼并保存用戶名和密碼，用戶名密碼保存到Client的FLASH中，點擊確定之后Client重新啟動，Client再次開機時發(fā)送的Discover報文中將在OPTION60字段authentication information field插入Message（其中Message為用戶名和密碼的加密字符串）。（2）DHCP平臺（包括DHCP服務器和認證服務器）收到Discover報文之后解析出OPTION60字段中的用戶名和密碼，并在本地所保存的用戶名信息庫中查找以進行真?zhèn)悟炞C。（3）DHCP平臺驗證用戶名、密碼，通過則向用戶返回Offer報文；沒有通過則丟棄該報文不做任何處理。（4）DHCP認證的實現(xiàn)過程不再詳述。

4.2 實驗結果

根據(jù)上面對DHCP定義的需求以及相應的接入認證方式，編寫相應的軟件代碼，交叉編譯之后下載到IPTV終端。啟動終端，通過截獲的網(wǎng)絡數(shù)據(jù)包來分析實驗結果。

4.2.1 DHCP開始。DHCP discover分為三組發(fā)送，每組2次，間隔8秒。如果終端任何一次收到服務器發(fā)來的DHCP offer和DHCP ack，會進入DHCP流程。不再繼續(xù)DHCP discover請求。在終端啟動后第2次發(fā)出DHCP discover（第8秒）報文后，如果收到服務器的DHCP offer回應，并且收到DHCP ack，將不會進行pppoe discover請求。

pppoe discover分為三組發(fā)送，每組3次，間隔10秒。pppoe第一次發(fā)包的時間點大約11.3s。若6次DHCP discover請求和9次pppoe discover都失敗后，則停止DHCP請求。其中，DHCP discover包里帶有“option 53、12、43、60”；DHCP request包里帶有“option 53、12、54、50、43、60”，DHCP release 包里帶有“option 53、54、61”。

4.2.2 DHCP續(xù)約。測試租期為100s，在租期內發(fā)送4次續(xù)約請求。在T1（50%租期）50s和T1.5（68.75%租期）68s會各發(fā)送一次request單播續(xù)約請求。在T2（87.5%租期）87s和T2.5（93.75%租期）93s會各發(fā)送一次request廣播續(xù)約請求。如果任何一次收到DHCP offer和DHCP ack，會進入DHCP流程。然后當又到T1時，又開始循環(huán)以上續(xù)約請求。

如果租期到期，但續(xù)約失敗，則會每隔8秒發(fā)送一次DHCP discover包。其中，DHCP discover包里帶有“option 53、12、43、60”，DHCP request包里帶有“option 53、12、54、50、43、60”。

4.2.3 測試結果。在續(xù)約失敗后，會每隔8秒發(fā)送一次DHCP discover包。但如果在此過程中收到了DHCP offer回應，則會連續(xù)發(fā)送兩次DHCP request請求，第一次是DHCP獲取IP地址的廣播請求。第二次是DHCP續(xù)約的單播請求，間隔1.5s。

5 結論

本文討論了基于嵌入式終端的DHCP+OPTION60的網(wǎng)絡接入及接入認證，通過截獲的網(wǎng)絡數(shù)據(jù)包證明了設計和實現(xiàn)的正確性。DHCP+接入認證技術相關協(xié)議標準還未最終制定，廠家之間的實現(xiàn)標準也尚不統(tǒng)一。DHCP+接入認證技術目前很難做到根據(jù)流量和時長進行計費，但可運營和可管理是運營商關注的問題，更是設備商要解決的問題。所以將得到進一步的發(fā)展。另外由于其開放性特點，其接入的安全性尚需更多的驗證和考驗。

參考文獻：

[1]朱金周.我國IPTV現(xiàn)狀與發(fā)展趨勢[J].人民郵電，2008，12，12.

[2]周曙光.PPPoE和DHCP相關協(xié)議分析及其在網(wǎng)絡機頂盒上的實現(xiàn)[D].電子科技大學碩士論文，2006，1，1.

[3]萬春艷.DHCP安全系統(tǒng)構架的研究[D].浙江大學碩士論文，2007，5.

[4]RFC1123：Requirements for Internet Hosts-Application and Support[S]

[5]田澤.嵌入式系統(tǒng)開發(fā)與應用[M].北京：北京航空航天大學出版社，2005，1.

[作者簡介]周斌（1981-），男，西華大學數(shù)學與計算機學院，碩士，講師，主要研究方向：計算機網(wǎng)絡、圖形圖像處理等。