Lwip，light weight IP；是由Adam Dunkels 開發(fā)的一個(gè)小型開源的TCP/IP協(xié)議棧；目前已經(jīng)為全球共同開發(fā)的開源協(xié)議；支持TCPIP協(xié)議族的核心協(xié)議；包括：ARP/ICMP/TCP/UDP/IPV4/IPV6/DHCP等；其核心特點(diǎn)是：功能齊全、運(yùn)行需求的RAM和ROM少；
編程模型所有的功能和性能都可進(jìn)行裁剪和配置；相關(guān)文件為：lwipopts.h
內(nèi)部實(shí)現(xiàn)支持帶操作系統(tǒng)和不帶操作系統(tǒng)；核心框架是：外部單線程驅(qū)動(dòng)協(xié)議棧狀態(tài)機(jī)；底層使用中斷進(jìn)行數(shù)據(jù)的接收；
其提供三種API ：1）RAW API 2）lwip API 3）BSD API。其中BSD API就是大家最熟悉的socket API了。Linux和Windows平臺(tái)中的socket接口都與此大同小異；
移植將lwip移植到不同的平臺(tái)主要包括兩個(gè)部分工作：
1.MAC+PHY層移植，包括初始化、數(shù)據(jù)的收發(fā)；
2.應(yīng)用層框架移植，如操作系統(tǒng)層的線程創(chuàng)建、定時(shí)器、消息郵箱；
平臺(tái)硬件：STM32F107 PHY芯片：DM9161AEP
軟件：UCOS-ii
移植核心點(diǎn)ST公司針對(duì)STM32F107 不帶操作系統(tǒng)版本的LWIP移植版本，文件名為STM32F107_ETH_LwIP，版本為V1.0.0；由于其版本不再更新且與本軟件平臺(tái)不一致，所以不做參考；
由于STM32F1 STM32F2 STM32F4的以太網(wǎng)驅(qū)動(dòng)都是一致的。所以到ST官網(wǎng)下載stm32cubdf2。其中有LWIP針對(duì)FREERTOS的移植；而FREERTOS與UCOS大同小異；所以只要針對(duì)其修改應(yīng)用層框架移植的實(shí)現(xiàn)即可；相關(guān)代碼位于：stm32cubef2STM32Cube_FW_F2_V1.1.0ProjectsSTM322xG_EVALApplicaTIonsLwIPLwIP_UDPTCP_Echo_Server_Netconn_RTOS；
LWIP的代碼使用1.4.1版本，可到LWIP官網(wǎng)上下載；也包含在stm32cubef2中；
移植的理論基礎(chǔ)來源于lwip 1.4.1源碼包中doc文件夾中的文件；同時(shí)官方也有移植到各個(gè)平臺(tái)中的示例，文件為：contrib-1.4.1.zip，到官網(wǎng)上下載即可；
1.MAC+PHY移植：
需要修改的文件為：
app_ethernet.c/h
etherneTIf.c/h
同時(shí)需要將stm32cubef2驅(qū)動(dòng)庫中的stm32f2xx_hal_eth.c/h拷貝過來；
以上文件只需要配置好，保證編譯沒問題，則MAC+PHY層移植完成；
2.應(yīng)用層框架移植：
修改1個(gè)文件sys_arch.c，位于stm32cubef2STM32Cube_FW_F2_V1.1.0MiddlewaresThird_PartyLwIPsystem；
所有的移植即完成；
實(shí)現(xiàn)lwip的DHCP自動(dòng)獲取ip地址 LM3S系列移植lwip自動(dòng)獲取ip的功能：實(shí)現(xiàn)過程是：1）在opt.h上使能#define LWIP_ARP 1和#define LWIP_DHCP 1；2）在lwipopts.h上使能#define LWIP_DHCP 1 和 #define DHCP_DOES_ARP_CHECK 1；3）在lwiplib.c上增加#include “lwip/dhcp.h”；4）最后在lwiplib.c上修改staTIc unsigned long g_ulIPMode = IPADDR_USE_DHCP和InitNic函數(shù)中的“ lwIPInit（MACAddress，xIpAddr， xNetMask， xGateway，IPADDR_USE_DHCP）；”。
調(diào)試過程： 一開始用網(wǎng)絡(luò)數(shù)據(jù)包分析軟件看，發(fā)現(xiàn)每隔幾秒實(shí)驗(yàn)板會(huì)發(fā)DHCP廣播給255.255.255.255，我不知道出現(xiàn)什么問題，后來看DHCP原理才知道，路由器沒回應(yīng)數(shù)據(jù)包，就覺得路由器不能自動(dòng)分配ip。我嘗試用pc機(jī)改成自動(dòng)獲取ip，原來真的不成功。后來發(fā)現(xiàn)之前修改路由器使能DHCP功能后沒重啟路由。重啟后，實(shí)驗(yàn)板也是先用DHCP廣播，接著路由器回應(yīng)一個(gè)ARP數(shù)據(jù)包給實(shí)驗(yàn)板，數(shù)據(jù)包里有給實(shí)驗(yàn)板分配的ip地址。接著實(shí)驗(yàn)板發(fā)出3次請(qǐng)問有誰是會(huì)占用自己將要獲得的ip，避免ip地址重復(fù)。之后什么數(shù)據(jù)都沒，我還以為沒成功獲得ip呢，因?yàn)樵诼酚善魃峡床灰妼?shí)驗(yàn)板已經(jīng)連上，后還我用ping，居然是通的，關(guān)閉實(shí)驗(yàn)板就ping不通，說明已經(jīng)獲得ip地址了，只是不明白在路由器上為什么不顯示連接成功。
DHCP工作原理：根據(jù)客戶端是否第一次登錄網(wǎng)絡(luò)，DHCP 的工作形式會(huì)有所不同。
第一次登錄的時(shí)候：
尋找 Server
當(dāng) DHCP 客戶端第一次登錄網(wǎng)絡(luò)的時(shí)候，也就是客戶發(fā)現(xiàn)本機(jī)上沒有任何 IP 數(shù)據(jù)設(shè)定，它會(huì)向網(wǎng)絡(luò)發(fā)出一個(gè) DHCP DISCOVER 封包。因?yàn)榭蛻舳诉€不知道自己屬于哪一個(gè)網(wǎng)絡(luò)，所以封包的來源地址會(huì)為 0.0.0.0 ，而目的地址則為 255.255.255.255 ，然后再附上 DHCP discover 的信息，向網(wǎng)絡(luò)進(jìn)行廣播。 在 Windows 的預(yù)設(shè)情形下，DHCP discover 的等待時(shí)間預(yù)設(shè)為 1 秒，也就是當(dāng)客戶端將第一個(gè) DHCP discover 封包送出去之后，在 1 秒之內(nèi)沒有得到響應(yīng)的話，就會(huì)進(jìn)行第二次 DHCP discover 廣播。若一直得不到響應(yīng)的情況下，客戶端一共會(huì)有四次 DHCP discover 廣播（包括第一次在內(nèi)），除了第一次會(huì)等待 1 秒之外，其余三次的等待時(shí)間分別是 9、13、16 秒。如果都沒有得到 DHCP 服務(wù)器的響應(yīng)，客戶端則會(huì)顯示錯(cuò)誤信息，宣告 DHCP discover 的失敗。之后，基于使用者的選擇，系統(tǒng)會(huì)繼續(xù)在 5 分鐘之后再重復(fù)一次 DHCP discover 的過程。
提供IP租用地址
當(dāng) DHCP 服務(wù)器監(jiān)聽到客戶端發(fā)出的 DHCP discover 廣播后，它會(huì)從那些還沒有租出的地址范圍內(nèi)，選擇最前面的空置 IP ，連同其它 TCP/IP 設(shè)定，響應(yīng)給客戶端一個(gè) DHCP OFFER 封包。 由于客戶端在開始的時(shí)候還沒有 IP 地址，所以在其 DHCP discover 封包內(nèi)會(huì)帶有其 MAC 地址信息，并且有一個(gè) XID 編號(hào)來辨別該封包，DHCP 服務(wù)器響應(yīng)的 DHCP offer 封包則會(huì)根據(jù)這些資料傳遞給要求租約的客戶。根據(jù)服務(wù)器端的設(shè)定，DHCP offer 封包會(huì)包含一個(gè)租約期限的信息。
接受IP租約
如果客戶端收到網(wǎng)絡(luò)上多臺(tái) DHCP 服務(wù)器的響應(yīng)，只會(huì)挑選其中一個(gè) DHCP offer 而已（通常是最先抵達(dá)的那個(gè)），并且會(huì)向網(wǎng)絡(luò)發(fā)送一個(gè)DHCP request廣播封包，告訴所有 DHCP 服務(wù)器它將指定接受哪一臺(tái)服務(wù)器提供的 IP 地址。 同時(shí)，客戶端還會(huì)向網(wǎng)絡(luò)發(fā)送一個(gè) ARP 封包，查詢網(wǎng)絡(luò)上面有沒有其它機(jī)器使用該 IP 地址；如果發(fā)現(xiàn)該 IP 已經(jīng)被占用，客戶端則會(huì)送出一個(gè) DHCPDECLIENT 封包給 DHCP 服務(wù)器，拒絕接受其 DHCP offer ，并重新發(fā)送 DHCP discover 信息。 事實(shí)上，并不是所有 DHCP 客戶端都會(huì)無條件接受 DHCP 服務(wù)器的 offer ，尤其這些主機(jī)安裝有其它 TCP/IP 相關(guān)的客戶軟件。客戶端也可以用 DHCP request 向服務(wù)器提出 DHCP 選擇，而這些選擇會(huì)以不同的號(hào)碼填寫在 DHCP OpTIon Field 里面。
換一句話說，在 DHCP 服務(wù)器上面的設(shè)定，未必是客戶端全都接受。客戶端可以保留自己的一些 TCP/IP 設(shè)定，并且主動(dòng)權(quán)永遠(yuǎn)在客戶端這邊。
租約確認(rèn)
當(dāng) DHCP 服務(wù)器接收到客戶端的 DHCP request 之后，會(huì)向客戶端發(fā)出一個(gè) DHCPACK 響應(yīng)，以確認(rèn) IP 租約的正式生效，也就結(jié)束了一個(gè)完整的 DHCP 工作過程。
DHCP 發(fā)放流程第一次登錄之后： 一旦 DHCP 客戶端成功地從服務(wù)器哪里取得 DHCP 租約之后，除非其租約已經(jīng)失效并且 IP 地址也重新設(shè)定回 0.0.0.0 ，否則就無需再發(fā)送 DHCP discover 信息了，而會(huì)直接使用已經(jīng)租用到的 IP 地址向之前之 DHCP 服務(wù)器發(fā)出 DHCP request 信息，DHCP 服務(wù)器會(huì)盡量讓客戶端使用原來的 IP 地址，如果沒問題的話，直接響應(yīng) DHCPack 來確認(rèn)則可。如果該地址已經(jīng)失效或已經(jīng)被其它機(jī)器使用了，服務(wù)器則會(huì)響應(yīng)一個(gè) DHCPNACK 封包給客戶端，要求其重新執(zhí)行 DHCP discover。 至于 IP 的租約期限卻是非?？季康模⒎侨缥覀冏夥孔幽菢雍?jiǎn)單， 以 NT 為例子：DHCP 客戶端除了在開機(jī)的時(shí)候發(fā)出 DHCP request 請(qǐng)求之外，在租約期限一半的時(shí)候也會(huì)發(fā)出 DHCP request ，如果此時(shí)得不到 DHCP 服務(wù)器的確認(rèn)的話，客戶端還可以繼續(xù)使用該 IP ；當(dāng)租約期過了87.5%時(shí)，如果客戶端仍然無法與當(dāng)初的DHCP服務(wù)器聯(lián)系上，它將與其它DHCP服務(wù)器通信。如果網(wǎng)絡(luò)上再?zèng)]有任何DHCP服務(wù)器在運(yùn)行時(shí)，該客戶端必須停止使用該IP地址，并從發(fā)送一個(gè)Dhcpdiscover數(shù)據(jù)包開始，再一次重復(fù)整個(gè)過程。要是您想退租，可以隨時(shí)送出 DHCPRELEASE 命令解約，就算您的租約在前一秒鐘才獲得的。
跨網(wǎng)絡(luò)的 DHCP 運(yùn)作 從前面描述的過程中，我們不難發(fā)現(xiàn)：DHCP DISCOVER 是以廣播方式進(jìn)行的，其情形只能在同一網(wǎng)絡(luò)之內(nèi)進(jìn)行，因?yàn)?router 是不會(huì)將廣播傳送出去的。但如果 DHCP 服務(wù)器安設(shè)在其它的網(wǎng)絡(luò)上面呢？由于 DHCP 客戶端還沒有 IP 環(huán)境設(shè)定，所以也不知道 Router 地址，而且有些 Router 也不會(huì)將 DHCP 廣播封包傳遞出去，因此這情形下 DHCP DISCOVER 是永遠(yuǎn)沒辦法抵達(dá) DHCP 服務(wù)器那端的，當(dāng)然也不會(huì)發(fā)生 OFFER 及其它動(dòng)作了。要解決這個(gè)問題，我們可以用 DHCP Agent （或 DHCP Proxy ）主機(jī)來接管客戶的 DHCP 請(qǐng)求，然后將此請(qǐng)求傳遞給真正的 DHCP 服務(wù)器，然后將服務(wù)器的回復(fù)傳給客戶。這里，Proxy 主機(jī)必須自己具有路由能力，且能將雙方的封包互傳對(duì)方。 若不使用 Proxy，您也可以在每一個(gè)網(wǎng)絡(luò)之中安裝 DHCP 服務(wù)器，但這樣的話，一來設(shè)備成本會(huì)增加，而且，管理上面也比較分散。當(dāng)然嘍，如果在一個(gè)十分大型的網(wǎng)絡(luò)中，這樣的均衡式架構(gòu)還是可取的。視您的實(shí)際情況而定了。
下載文檔
