網(wǎng)絡(luò)部分重要的tcpip init函數(shù)是LwIP提供一個API負(fù)責(zé)完成

tcpip_init()LwIPAPITCPIP層的初始化及處理線程的建立工實(shí)際上，LwIPIPMAC地址的網(wǎng)絡(luò)接口，這些接口可以獨(dú)立處理網(wǎng)絡(luò)通訊而不互相干擾。LwIP把它們以鏈表的方如果我們采用函數(shù)調(diào)用的方式把底層接收函數(shù)得到的IP包作為參數(shù)傳遞給ip_input()，那ETH_IRQHandler網(wǎng)絡(luò)中斷函數(shù)里面發(fā)送消息到這個線程這幾行代碼完成數(shù)據(jù)向IPARP表，然后跳過以太網(wǎng)幀頭，最后傳遞給IP協(xié)議處理模塊，在這里實(shí)際上就是把收到的數(shù)據(jù)交給tcpip_input()函數(shù)。申請接收緩沖區(qū)――pbuf，然后調(diào)用EMACReadPacket()函數(shù)把EMAC收到的數(shù)據(jù)搬運(yùn)到pbuf中，完成EAMC到協(xié)議棧的數(shù)據(jù)轉(zhuǎn)移工作。pbuf_alloc()poolpbufsUDPUDP話路(session)的狀態(tài)都被保留在一個PCB7UDPPCBsUDPdatagramUDPPCBUDPPCBPCBUDP話路(session)由IP地址和端來定義，并且被存放local_ip,dest_ip,local_port,dest_port域中。Flags域這一話路（session）UDPUDPchecksummingUDP輕便在哪個檢驗(yàn)數(shù)字蓋住只數(shù)據(jù)報的部分。ThiscanbeeithertoswitchUDPchecksummingoffcompley,ortouseUDPLite[LDP99]inwhichthechecksumcoversonlypartsofthedatagramIfUDPLiteisused,thechksumlenfieldspecifieshowmuchofthedatagramthatshouldbechecksummed.PCBsessiondatagramrecvrecv_arg將被使datagram時，recv所指向的函數(shù)被調(diào)用。TCP數(shù)據(jù),tcp_write()tcp_write()來函數(shù)tcp_output()將檢查數(shù)據(jù)是否可以發(fā)送。也就是說，如果的窗口有足夠的空間()IPTCPtcp_input()初始檢驗(yàn)(,checksummingTCP剖析析)TCP連接。該段于是由tcp_process()處理,它實(shí)現(xiàn)TCP狀態(tài)機(jī)和其他任何必須的狀態(tài)轉(zhuǎn)換。。如果接處于tcp_receivetcp_receive()將把段上傳tcp_output()將被調(diào)用。Netbufs6.1netbufpbuf之間的內(nèi)部關(guān)聯(lián)。Netbufs可以當(dāng)做pbufs容納分配的內(nèi)存和的內(nèi)存。數(shù)據(jù)在netbuf里面可以是不同大小的碎片塊，這意味著應(yīng)用程序必須準(zhǔn)備好接受零碎的數(shù)據(jù)。netbuf內(nèi)部有一個指針指向netbuf里面的一個碎片，netbuf_next()和netbuf_first()兩個函數(shù)就是利用了這個指針。low_level_init函數(shù)里面創(chuàng)建了ethernetif_input二、在tcpip_init函數(shù)里面創(chuàng)建了tcpip_threadIP部分傳遞。tcpecho_inittcpecho_thread任務(wù)，等待接收數(shù)據(jù)。四、在tcpecho_init 中有tcpecho_thread->netconn_new(NETCONN_TCP)-> accept_function->setup_tcp(newconntcp_recv(pcb,recv_tcp)->recv_tcp2015611TCP服務(wù)器的程序，相比以前來說，移植略微有點(diǎn)繁瑣，多了以下幾點(diǎn)一、跟原來一樣，添加了LwIP的協(xié)議。tcp_echo_server的應(yīng)用程序。三、添加了板級支持包的STM32_EVAL。四、添加了網(wǎng)卡的驅(qū)動LIBRARY\STM32F2x7_ETH_Driver。五、自己在port 下面添加了一個關(guān)于UCOS-III的文件。IPMACIP地址、掩碼地址和網(wǎng)關(guān)地址在LwIP_Init函數(shù)里面。MAClow_level_init函數(shù)里面。好像配置MAC2015615第一、我最開始在兩臺電腦上面互相發(fā)現(xiàn)不同，經(jīng)過別人的指點(diǎn)，原來是兩臺腦沒有關(guān)閉，電腦之間相互互相關(guān)閉的。–當(dāng)前的端口正在使用，如果還有第二個網(wǎng)卡，就不能使用這個端了。別的電腦作為端，配置如原來邊工發(fā)給我的工程里面，直接操作串口的方式是在kernel\lwip-1.3.0\src\arch 201578—，，面卻發(fā)現(xiàn)問題不通。一開始不知道怎么查，邊工跟我說的時候可以檢查一下DMA的數(shù)組這個是與底層打交道的數(shù)組它在LwIP_Init(false)->netif_add(&main_net, ethernetif_init->BSP_InitEth()->Tx_Buff&Rx_Buff。在stm32f2x7_eth.c文件的68行。，，在正常的時候這里面都可以看到Tx_Buff里面的[0]-[4]都有IP地址信息而在不通的情況之下Rx_Buff里面[0]-[4]IP信息，其它的信息看不出有什么實(shí)際的意可以很明顯的看到數(shù)據(jù)的接收出現(xiàn)了問題，對照著從網(wǎng)上的LWIP1.4.0版本仔細(xì)看了一下，原來好像是采用中斷方式接收數(shù)據(jù)，而板子例程上面提供的是查詢方式，在ETH_IRQHandler時候加上了使能網(wǎng)絡(luò)中斷部分，在stm32f2x7_eth_bsp.c文件的515行加上了ETH_DMAITConfig(ETH_DMA_IT_NIS|ETH_DMA_IT_R,ENABLE);就正常了。二OSDly110秒鐘才有一次斷點(diǎn)，很明顯，是時鐘沒有設(shè)置正確，影響到其它的任務(wù)了，于是通過clock查找工程中相三之后的一段時間主要是在網(wǎng)上找資料，找到當(dāng)年寫程序最原始的一本書《Linux網(wǎng)絡(luò)編14accept客戶端，另外一select看看已經(jīng)有的文件描述符是否有變化，這樣的操作效率是最高的。四2015721單步，在tcpip.c文件里面的73行tcpip_thread任務(wù)里面，發(fā)現(xiàn)了memp_2 ShowCallerCode3到了這一步，就開始找數(shù)據(jù)有多大，來源是什么，在sockets.c文件里面630行l(wèi)wip_recvfrom函數(shù)里面，發(fā)現(xiàn)buflen是0x1E1F，最開始我以為是自己定義的7711BYTE，而在傳送正常Linux的時候用到的是Wireshark，但是評論說這個軟件用起來比較麻煩，用這個軟件IpTool比較好點(diǎn)。于是在網(wǎng)上了這個軟件，關(guān)45copy的源地址和目標(biāo)地址，也沒有發(fā)現(xiàn)什么樣的問題。接著我懷疑是不是我這個網(wǎng)絡(luò)調(diào)試助手工具出現(xiàn)了問題，于是我在網(wǎng)上了好幾個類似的軟件，6201575api_msg.c218recv_tcp函數(shù)里面，這個CallStack+Localsrecv_tcpShowCallerCode就到了。7tcp_in.c328行，沒有重啟運(yùn)行速度過快導(dǎo)致程序出現(xiàn)了一些，于是我在tcpip_thread這個任務(wù)里面加上8文件里面的168行加上一個判斷，如果是0x11，則把它修改為0x14，這樣就沒有任后來我在這里修正了一下，在ethernetif.cpbuf_t*low_level_input(structnetif*netif)函數(shù)里面進(jìn)行了修正。sockets.c380opt.h330行的MEMP_NUM_NETCONN，40次。 應(yīng)該在tcp_in.c的330 366行的else語句是自己加的tcp_in.c的168行語句是自己加的staticerr_trecv_tcp(void*arg,structtcp_pcb*pcb,structpbuf*p,err_terr)recv_flags&TF_GOT_FINstatictcp_process(structtcp_pcb*pcb)u8u8_trecv_flags;if(p== staticvoid{//sys_sem_signal(&lwip_eth_sem);}if(err!=ERR_ABRT)if(recv_flags&TF_RESET)/*TF_RESETmeansthattheconnectionwasresetbytheotherend.WethencalltheerrorcallbacktoinformtheapplicationthattheconnectionisdeadbeforewedeallocatethePCB.*/tcp_pcb_remove(&tcp_active_pcbs,pcb);}/*IfaFINsegmentwasreceived,wecallthecallbackfunctionwithaNULLbuffertoindicateEOF.*/if(recv_flags&TF_GOT_FIN)/*correctrcv_wndastheapplicationwon'tcalltcp_recved()fortheFIN'sseqno*/if(pcb->rcv_wnd!=TCP_WND){}TCP_EVENT_CLOSED(pcb,err);if(err==ERR_ABRT){goto}}recv120x11這樣的指令，經(jīng)過我的修正之后都是一樣的。這里糾30x11，而全速運(yùn)行4經(jīng)過查看資料，找到了接收底層數(shù)據(jù)的函數(shù)，在ethernetif.c文件的123行355致程序掛掉呢？那到底是什么原因促使沒有及時回復(fù)呢？在哪里回復(fù)呢？于是我在底層發(fā)送的部分，也就是ettic0行l(wèi)_leelttttetif*net,ttf*p)tcp_in.c451tcp_rst這個部分，條6tcphdr->_hdrlen_rsvd_flags0x19，會有一個回復(fù)令，而全速運(yùn)行的時候tcphdr->_hdrlen_rsvd_flags是0x14，沒有回復(fù)命令，于是我在這里加上了一個判斷，如果是0x14，就把它修改為0x19。其實(shí)我至今都不明白為0x190x19肯定是對的。7recv的返回值是負(fù)數(shù)，而全速運(yùn)行的時都把conn->last_err設(shè)置成為0xF5，也就是重啟的指令，而在這里的356行就是錯誤的5為什么卻不執(zhí)行這里的返回值呢？直接返回狀態(tài)無錯誤的狀態(tài)呢？終于發(fā)現(xiàn)問題的關(guān)鍵點(diǎn)22代碼本來應(yīng)先判斷統(tǒng)的狀態(tài)后再數(shù)但是這里很顯的是沒有判系斷開的狀下直接數(shù)據(jù)。8*conn,void**new_buf)函數(shù)里面確實(shí)是先判斷狀態(tài)，然后數(shù)據(jù)，但是數(shù)據(jù)是采用pend等待數(shù)據(jù)，也就是確認(rèn)之前的狀態(tài)沒有問題了才數(shù)據(jù)，它并沒有對后的數(shù)據(jù)9 conn->last_err=err=conn-/*don'trecvonfatalerrors:thismightblocktheapplicationtaskwaitingonrecvmboxforever!*//*@todo:thisdoesnotallowustofet