I’m running the FreeRTOS TCP/IP stack and we want to be able to ask the DHCP server for a new address under certain conditions. I assume that must be possible. If so, would anyone be able to tell me how please?
Also, where can I get the value for the current IP address just by breaking the progrm and looking with the debugger?
Finally, when I receive a UDP packet, if I understand correctly, the sending address should be xAddress in the following
That’s an interesting question / request.
Can I ask why you want to poll DHCP again? Is that after a dip in the Link Status of the PHY?
There is a way to “re-initiate” the TCP/IP stack, by calling:
FreeRTOS_NetworkDown();
The network-down-event will call:
xNetworkInterfaceInitialise(); // See NetworkInterface.c
( note that xNetworkInterfaceInitialise() must be aware that it can be called more than once. It must first check if it is being called for the first time. )
and it will also call:
/* The network is not up until DHCP has completed. */
vDHCPProcess( pdTRUE );
When the DHCP negotiation is ready, or after it has reached a timed-out, the function:
void vIPNetworkUpCalls();
will be called, which will also call:
vApplicationIPNetworkEventHook( eNetworkUp );
After a change of the IP-address (or netmask), you should reset or re-create all sockets. That is quite heavy.
Maybe you can check in vApplicationIPNetworkEventHook( eNetworkUp ) if any of the NIC data has changed, thus preventing unnecessary resets.
It’s an unusual set-up where each unit gets a specific dynamic IP address depending on which port on the switch in to which it is plugged.
They were wanting to be able to unplug from one port, plug in to another and have its IP address updated. However, having talked it over with them they have been persuaded that this is not a realistic situation in the real world.
So, looks like the requirement has gone away!
I am still wondering about which variable holds the dynamic IP address. I tried looking at the variables in FreeRTOS_GetAddressConfiguration, but it just told me they didn’t exist if I just randomly stop the debugger.
From a debugger you can monitor the struct xNetworkAddressing, defined in FreeRTOS_IP.c :
/* Structure that stores the netmask, gateway
address and DNS server addresses. */
typedef struct xNetworkAddressingParameters
{
uint32_t ulDefaultIPAddress;
uint32_t ulNetMask;
uint32_t ulGatewayAddress;
uint32_t ulDNSServerAddress;
uint32_t ulBroadcastAddress;
} xNetworkAddressingParameters_t;
xNetworkAddressingParameters_t xNetworkAddressing;
All fields except ulDefaultIPAddress will be set by DHCP. ulDefaultIPAddress will be copied to *ipLOCAL_IP_ADDRESS_POINTER in case DHCP does not reply.
At this moment +TCP defines a single IP- and MAC-address which can be found in:
/* The local IP address is accessed from within xDefaultPartUDPPacketHeader,
rather than duplicated in its own variable. */
#define ipLOCAL_IP_ADDRESS_POINTER ( ( uint32_t * ) &( xDefaultPartUDPPacketHeader.ulWords[ 20 / sizeof(uint32_t) ] ) )
/* The local MAC address is accessed from within xDefaultPartUDPPacketHeader,
rather than duplicated in its own variable. */
#define ipLOCAL_MAC_ADDRESS ( &xDefaultPartUDPPacketHeader.ucBytes[0] )
These defines are not debugger-friendly
They existed in the earlier +UDP stack already. It had a xDefaultPartUDPPacketHeader which was memcpy’d to create a new UDP message.
I would still like to see some changes to the DHCP process:
Get a call which starts a new silent DHCP request. It will just “poll” the DHCP server for any changes.
Store the new DHCP data into a temporary struct so they can be compared with the data currently in use.
Keep a complete set of default values in xDefaultAddressing.
/* Values currently used by the TCP/IP stack. /
xNetworkAddressingParameters_t xNetworkAddressing;
/ Values copied to xNetworkAddressing in case there
is no response from any DHCP server. */
xNetworkAddressingParameters_t xDefaultAddressing;
The field ulDefaultIPAddress will be renamed to ulIPAddress.
