+TCP DCHP addition idea/request

Kernel
1

friesen wrote on Friday, September 06, 2019:

Due to the way a wifi module doesn’t connect immediately, if dhcp tries too soon things don’t work as expected. Perhaps I’m doing something wrong here, but to mitigate this, I did this:

in FreeRTOS_DHCP.h

typedef enum eDHCP_ANSWERS
{
    eDHCPDelay, /* <-----  Delay option */
	eDHCPContinue,			/* Continue the DHCP process */
	eDHCPUseDefaults,		/* Stop DHCP and use the static defaults. */
	eDHCPStopNoChanges,		/* Stop DHCP and continue with current settings. */
} eDHCPCallbackAnswer_t;

in FreeRTOS_DHCP.c

in void vDHCPProcess( BaseType_t xReset )

This hook allows me to delay DHCP until the network interface is completely ready.

		case eWaitingSendFirstDiscover :
			/* Ask the user if a DHCP discovery is required. */
		#if( ipconfigUSE_DHCP_HOOK != 0 )
			eAnswer = xApplicationDHCPHook( eDHCPPhasePreDiscover, xNetworkAddressing.ulDefaultIPAddress );
			if( eAnswer == eDHCPDelay){
			    /* Do nothing, delay */
			} else if( eAnswer == eDHCPContinue )
		#endif	/* ipconfigUSE_DHCP_HOOK */

This hook allows me to do something if DHCP fails.

	if( xGivingUp != pdFALSE )
	{
		/* xGivingUp became true either because of a time-out, or because
		xApplicationDHCPHook() returned another value than 'eDHCPContinue',
		meaning that the conversion is canceled from here. */
		#if( ipconfigUSE_DHCP_HOOK != 0 )
		eAnswer = xApplicationDHCPHook( eDHCPPhaseFailed, xNetworkAddressing.ulDefaultIPAddress );
		#endif	/* ipconfigUSE_DHCP_HOOK */

Any comments on this approach, could this be considered, or is there another way to get there?

2

heinbali01 wrote on Friday, September 06, 2019:

Hello Erik, I would like to take another path.

For people using DHCP, you solve a problem, because you can delay the DHCP processing. But what if another user doesn’t enable DHCP. His first messages would get lost.

When the IP-task starts up, it will call xNetworkInterfaceInitialise() every 3 seconds until it returns the value pdPASS.

Does your WiFi driver know when the interface is ready to exchange messages?

I would propose to change xNetworkInterfaceInitialise() and have it return a pdPASS as soon as the WiFi interface is ready to transmit messages. Could that be done?

3

friesen wrote on Friday, September 06, 2019:

Are you saying that this is already in place now? I think for this to work properly that prvProcessNetworkDownEvent isn’t going to be able to call FreeRTOS_NetworkDown() every time pdFALSE is returned? Otherwise this would work fine I think.

What about the DHCP failed hook?

4

heinbali01 wrote on Saturday, September 07, 2019:

Are you saying that this is already in place now?

I think for this to work properly that prvProcessNetworkDownEvent
isn’t going to be able to call FreeRTOS_NetworkDown() every time
pdFALSE is returned?

That is the way how it works. The function prvProcessNetworkDownEvent() keeps on sending a message of the type eNetworkDownEvent.

So in fact it works like this:

    while( xNetworkInterfaceInitialise() == pdFAIL )
    {
        vTaskDelay( ipINITIALISATION_RETRY_DELAY );
        FreeRTOS_NetworkDown();
    }
    /* Initialise the DHCP process. */
    vDHCPProcess( pdTRUE );

What about the DHCP failed hook?

Do you mean iptraceDHCP_REQUESTS_FAILED_USING_DEFAULT_IP_ADDRESS() ?
You can set that macro in your FreeRTOSIPConfig.h. But note that there is not a second chance for DHCP, other than reboot the device.

The most important thing here is xNetworkInterfaceInitialise() : only the driver can know exactly when the link is fully operational.