LWIP modifies the ip tcp sending connection status

Application: 1. Remote modification of configuration information such as local IP address without restarting the protocol stack 2. TCP sends an endless loop immediately or does not need to be sent immediately 3. Method A for determining the connection status with the server, sending success callback function (accurate) B. lm3s network connection status register (only local network connection status can be determined) C. tcp_pcb status (inaccurate) D. Added heartbeat Mechanism
Title: [reprinted] problems with Protocol Gateway LWIP 20:35:28

I have been using Ti chips for three years. I have developed low-power wireless sensors, wireless to Ethernet gateways, and other devices. Now let's talk about some problems encountered in the wireless to Ethernet gateway device developed with the lm3s9b90 chip! Ethernet uses the LWIP protocol. This is the first time that I use a 32-bit server, an ARM kernel chip, and LWIP; At first, I had no confidence that I would do well. With the help of Ti routines and technical support, I had to design the product within six months and run it quite stably. The biggest problem encountered during this process is TCP running: (the first two are minor issues, and the last one is fatal) Problem 1: IP Address allocation problem. At that time, we used the routine method to call lwipinit and lwiplocalipaddrget to obtain the IP address. What if the network cable was not connected at the time or the DHCP function was not enabled on the router? At first, I used the method of re-calling the above functions for processing and found that the system would reset. Obviously, this method does not work, Later, through understanding LWIP, we found that we can call the lwipnetworkconfigchange function by modifying the IP address, and set the IP address to the IP address allocated last time. In this way, as long as the device has been used normally, there will be no problems in the future! Problem 2: Call the tcp_output function. To improve the sending speed, call the tcp_output function before calling the tcp_write function each time. After adding this function, after a short period of time, the system will be reset. After a series of searches, the tcp_output function is finally locked. After cancellation, the system is no longer Reset Problem 3: handling network exceptions. during normal use, the device network cable is disconnected, the server network cable is disconnected, the server software is closed, and the server computer is crashed, the other several cases are well identified, but the server network cable is disconnected, which cannot be distinguished; When the server network cable is disconnected (the connection between the device and the vro is good), the device will not receive an exception report, nor will it have the register mark. It can only send data to the server, determine whether a callback function has been sent. If no callback function is available, the server link must be faulty. Once the server network cable is disconnected, the PCB> state in the LWIP of the device processes the link successfully. The server deletes the link after a certain period of time, that is, after a certain period of time, the connection status between the device and the server is different. At the same time, the device remains in a false link and will not be connected to the server again; As a result, the connection between the server and the device is never possible. This problem has plagued us for a long time, and is only found in the use of the customer, the customer's pressure can be imagined. Fortunately, after a period of troubleshooting, I finally found the problem and the solution to the problem: In the same way as the server, after a timeout period, the server actively disconnects the connection with the server (vro) and sends the close command to the server, the PCB enters the fin_wait_1 and fin_wait_2 statuses. If the link is connected during the period, the service returns ack to confirm the link is closed. Otherwise, the device automatically enters the close status after the timeout, and the connection status at both ends is consistent; once the link returns to normal, the device and server can establish a normal connection again. This problem is finally solved. The device has been running for almost half a year. No problems have been found so far. LWIP source code analysis Http://wenku.baidu.com/view/84a478a2284ac850ad024263.html LWIP status Status: Description Closed: No connection is active or in progress Listen: the server is waiting for incoming call Syn_recv: a connection request has arrived, waiting for confirmation Syn_sent: The application has started. Open a connection. Established: normal data transmission status Fin_wait1: The application says it has been completed Fin_wait2: the other side has agreed to release Itmed_wait: wait until all groups die Closing: both sides attempt to close at the same time Time_wait: the other side has initialized a release. Last_ack: waiting for all groups to die This article mainly describes the sending part of the TCP function. Our process is tcp_write-> tcp_enqueue-> tcp_output. 1. tcp_write Function This function is very simple. First, determine whether the PCB is in the status where data can be sent. These statuses include established, close_wait, syn_sent, syn_recd, and some other statuses seen in the state machine, for example, listen, fin_wait1, fin_wait2, closed, and closing are either in a connection that has not yet been established or the connection has been closed. At most, an ACK packet can be sent and no data can be sent) if it is in these valid states, call the tcp_enqueue function.   2. tcp_enqueue Function Tcp_enqueue puts the data packets to be sent from the upper layer in the queue, and CALLS tcp_output together to improve efficiency. Take a look at the parameters: Tcp_enqueue (struct tcp_pcb * PCB, void * Arg, u16_t Len, u8_t flags, u8_t apiflags, u8_t optflags) PCB: The current connected PCB, Arg: The data to be sent, Len: The data length, flags: the flag of the TCP header. Apiflags: tcp_write_flag_copy (this indicates that the space needs to be allocated and copied to pbuf; otherwise, the data comes from static storage, such as Rom, and does not need to be copied) tcp_write_flag_more.   View the code process: A. First, save some variables, such as the length of the data to be transmitted and the address of the data to be transmitted. B. Cut the data to be transmitted into a tcp_seg struct. The maximum length cannot exceed one MSS. If it is less than one, it is a tcp_seg. It is strange that the first seg is stored in the queue of the queue pointer, and the rest is stored in the queue of the useg pointer, and useg always points to the last seg struct. C. After data cutting, we need to add these seg to the PCB> unsend queue. But this code is very strange. I don't know if I have read it wrong or if I have a bug? But theoretically there won't be such an obvious bug.   3. tcp_output Function In the tcp_enqueue function, we have placed the data we want to send on the PCB unsend linked list. Next we will send the data. View process: A. First, the flags are filtered out for calls that immediately respond and do not carry data. tcp_send_empty_ack (PCB) is used directly. (because not every call to tcp_output passes through tcp_enqueue) B. Use the while loop to send or skip the seg ON THE unsend linked list one by one. A) SKIP: The Nagle algorithm is used to check each seg package. If the Nagle condition is met, the data packet is skipped and no operation is performed. For specific conditions, refer to the article in the TCP concept section. B) Send: for general seg packages, set the ACK flag and call tcp_output_segment (SEG, PCB.   4. About tcp_send_empty_ack (PCB) in tcp_output ); A) the operation here is relatively simple, mainly to establish pbuf, then establish the connection between the TCP header and pbuf, tcphdr = p-> payload, then fill in tcphdr, and pass it to the IP layer. (Call the ip_output function) 5. About tcp_output_segment (SEG, PCB) in tcp_output ); A) similar to tcp_send_empty_ack (PCB), it is not very complicated. Original post address: http://www.deyisupport.com.sixxs.org/question_answer/f/23/t/5240.aspx? Pageindex = 8 Author: Hasten Lin on