Lwip get ip address description

Lwip, light weight IP; is a small open source TCP/IP protocol stack developed by Adam Dunkels; an open source protocol that has been jointly developed for the world; a core protocol supporting the TCPIP protocol family; including: ARP/ICMP/TCP/UDP/ IPV4/IPV6/DHCP, etc.; its core features are: full-featured, less RAM and ROM for running requirements;

All functions and performance can be cropped and configured; the relevant file is: lwipopts.h

The internal implementation supports operating system with and without operating system; the core framework is: external single-threaded driver protocol stack state machine; the underlying uses interrupt to receive data;

It provides three APIs: 1) RAW API 2) lwip API 3) BSD API. The BSD API is the socket API that everyone is most familiar with. The socket interfaces in Linux and Windows platforms are similar to each other;

Porting lwip to different platforms mainly involves two parts:

1. MAC+PHY layer migration, including initialization, data transmission and reception;

2. Application layer framework porting, such as thread creation, timers, and message mailboxes of the operating system layer;

Hardware: STM32F107 PHY chip: DM9161AEP

Software: UCOS-ii

ST company for the STM32F107 LWIP port version without operating system version, the file name is STM32F107_ETH_LwIP, the version is V1.0.0; because its version is no longer updated and is inconsistent with the software platform, it is not for reference;

The Ethernet drivers for the STM32F1 STM32F2 STM32F4 are identical. So go to the ST official website to download stm32cubdf2. Among them, LWIP is for the transplantation of FREERTOS; FREERTOS is similar to UCOS; so just modify the implementation of the application layer framework for it; the relevant code is: stm32cubef2\STM32Cube_FW_F2_V1.1.0\Projects\STM322xG_EVAL\ApplicaTIons\LwIP\LwIP_UDPTCP_Echo_Server_Netconn_RTOS;

The LWIP code is version 1.4.1 and can be downloaded from the LWIP website; it is also included in stm32cubef2;

The theoretical basis of the transplantation comes from the files in the doc folder of the lwip 1.4.1 source package; at the same time, the official example is also transplanted to each platform, the file is: contrib-1.4.1.zip, can be downloaded to the official website;

1.MAC+PHY porting:

The files that need to be modified are:

App_ethernet.c/h

etherneTIf.c/h

At the same time, you need to copy stm32f2xx_hal_eth.c/h in the stm32cubef2 driver library;

The above files only need to be configured to ensure that the compilation is no problem, then the MAC+PHY layer is migrated;

2. Application layer framework migration:

Modify 1 file sys_arch.c, located at stm32cubef2\STM32Cube_FW_F2_V1.1.0\Middlewares\Third_Party\LwIP\system;

All transplants are completed;

The implementation process is: 1) enable #define LWIP_ARP 1 and #define LWIP_DHCP 1 on opt.h; 2) enable #define LWIP_DHCP 1 and #define DHCP_DOES_ARP_CHECK 1 on lwipopts.h; 3) add on lwiplib.c #include "lwip/dhcp.h"; 4) Finally modify the staTIc unsigned long g_ulIPMode = IPADDR_USE_DHCP and "itwIPInit(MACAddress, xIpAddr, xNetMask, xGateway, IPADDR_USE_DHCP);" in lwiplib.c.

The debugging process: I started with the network packet analysis software and found that every few seconds, the experiment board will send a DHCP broadcast to 255.255.255.255. I don't know what the problem is. After seeing the DHCP principle, the router does not respond to the packet. I think the router can't automatically assign ip. I tried to use the PC to change to automatically get ip, it turned out to be really unsuccessful. Later, it was found that the router was not restarted after the router was enabled to enable the DHCP function. After restarting, the experiment board is also broadcasted by DHCP first, and then the router responds to an ARP packet to the experiment board, and the data packet contains the IP address assigned to the experiment board. Then the experiment board sends out 3 times. Will anyone take up the ip that they will get, avoiding duplicate IP addresses. After that, no data, I thought that I did not succeed in getting ip, because I can't see the experiment board on the router has been connected, after I use ping, it is actually through, close the experiment board can not ping, indicating that the ip address has been obtained However, I just don't understand why the connection is not displayed successfully on the router.

The working form of DHCP varies depending on whether the client logs in to the network for the first time.

When logging in for the first time:

Looking for Server

When the DHCP client logs in to the network for the first time, that is, the client finds that there is no IP data setting on the machine, it will send a DHCP DISCOVER packet to the network. Because the client does not know which network it belongs to, the source address of the packet will be 0.0.0.0 and the destination address will be 255.255.255.255, and then the information of DHCP discover will be attached to broadcast to the network. In the default situation of Windows, the wait time of DHCP discover is preset to 1 second, that is, when the client sends the first DHCP discover packet and does not get a response within 1 second, it will perform the second. Secondary DHCP discover broadcast. If there is no response, the client will have four DHCP discover broadcasts (including the first time), except for the first time, waiting for 1 second, the other three waiting times are 9, 13 respectively. , 16 seconds. If no response is received from the DHCP server, the client will display an error message stating that DHCP discover failed. After that, based on the user's choice, the system will continue to repeat the DHCP discover process after 5 minutes.

Provide IP lease address

When the DHCP server listens to the DHCP discover broadcast sent by the client, it selects the first vacant IP from the range of addresses that have not yet been leased, and responds to the client with a DHCP OFFER packet along with other TCP/IP settings. . Since the client does not have an IP address at the beginning, it will have its MAC address information in its DHCP discover packet, and it has an XID number to identify the packet. The DHCP offer packet responded by the DHCP server will be transmitted according to these data. For customers who require a lease. According to the settings on the server side, the DHCP offer packet will contain a lease term information.

Accept IP lease

If the client receives a response from multiple DHCP servers on the network, it will only pick one of the DHCP offers (usually the one that arrived first) and will send a DHCP request broadcast packet to the network, telling all DHCP servers that it will specify Which IP address the server provides. At the same time, the client will send an ARP packet to the network to check whether there are other machines on the network that use the IP address. If the IP is already occupied, the client will send a DHCPDECLIENT packet to the DHCP server and refuse to accept the DHCP offer. And resend the DHCP discover information. In fact, not all DHCP clients will unconditionally accept the offer of DHCP servers, especially if they have other TCP/IP related client software installed. The client can also use the DHCP request to make a DHCP selection to the server, and these choices will be filled in the DHCP OpTIon Field with different numbers.

In other words, the settings on the DHCP server are not necessarily accepted by the client. The client can keep some of its own TCP/IP settings, and the initiative is always on the client side.

Lease confirmation

When the DHCP server receives the DHCP request from the client, it sends a DHCPACK response to the client to confirm that the IP lease is officially valid, which ends a complete DHCP work process.

After the DHCP login process is logged in for the first time: Once the DHCP client successfully obtains the DHCP lease from the server, there is no need to send DHCP discover information unless its lease has expired and the IP address is reset back to 0.0.0.0. The DHCP request message will be sent directly to the previous DHCP server using the IP address already leased. The DHCP server will try to let the client use the original IP address. If there is no problem, directly respond to the DHCPack to confirm. If the address has expired or is already in use by another machine, the server will respond to a DHCPNACK packet to the client requesting it to re-execute DHCP discover. As for the lease term of IP, it is very elegant. It is not as simple as renting a house. Take NT as an example: In addition to issuing a DHCP request request at boot time, the DHCP client will also issue a DHCP request at half the lease term. If the DHCP server does not get confirmation at this time, the client can continue to use the IP; when the lease expires 87.5%, if the client still cannot contact the original DHCP server, it will interact with other DHCP servers. Communication. If no DHCP server is running on the network, the client must stop using the IP address and start the process by repeating the Dhcpdiscover packet. If you want to retire, you can always send a DHCPRELEASE command to cancel the contract, even if your lease was acquired in the previous second.

DHCP operation across the network From the process described above, we can easily find that DHCP DISCOVER is broadcasted, and the situation can only be carried out within the same network, because the router will not transmit the broadcast. But what if the DHCP server is installed on other networks? Since the DHCP client does not have an IP environment setting, it does not know the Router address, and some Routers will not pass the DHCP broadcast packet. Therefore, in this case, the DHCP DISCOVER will never reach the DHCP server. Of course, OFFER and other actions will occur. To solve this problem, we can use the DHCP Agent (or DHCP Proxy) host to take over the client's DHCP request, then pass the request to the real DHCP server, and then pass the server's reply to the client. Here, the Proxy host must have its own routing capability and can pass the packets from each other to each other. If you don't use Proxy, you can also install a DHCP server in each network, but in this case, the cost of the device will increase, and the management is also scattered. Of course, if you are in a very large network, such a balanced architecture is still desirable. It depends on your actual situation.