I’m having a bit of trouble with reliable dhcp. It would appear that dhcp tries as soon as I call FreeRTOS_IPInit() whether or not the Wifi interface is ready. There really is no good way for the application to either query dhcp status or be warned if the process failed. Any suggestions? It would seem to me that we need to either extend vIPNetworkUpCalls or xApplicationDHCPHook to include this information, or allow delaying dhcp until ready. I don’t really like the silent failures that can happen with a ulrand failure, like line 593 in FreeRTOS_DHCP.c

Not a direct reply – but can you initialise WiFi first, then call FreeRTOS_IPInit()?

I could, although its probably better to call FreeRTOS_NetworkDown() for a cleaner api.

I am calling NetworkDown to reset dhcp, I thought, but I don’t really make sense of these logs, timeline wise. <2> 10/05/18 15:45:21.870 IP: Network down <2> 10/05/18 15:45:22.820 IP: Network down <2> 10/05/18 15:45:22.870 IP: Network down <1> 10/05/18 15:45:23.310 WIFI: m2mwificonnect success <2> 10/05/18 15:45:23.820 IP: Network down <1> 10/05/18 15:45:23.820 DHCP: Request <1> 10/05/18 15:45:23.090 DHCP: Request <2> 10/05/18 15:45:23.090 IP: Network down <1> 10/05/18 15:45:29.510 DHCP: Request <1> 10/05/18 15:45:29.710 DHCP: address 192.168.0.9

I think that perhaps these DHCP requests are added to the list, but not removed if there is a network issue? Then when the network becomes available a number of requests get sent out.

The problem is that I am calling FreeRTOS_NetworkDown() too many times. Is there any thing that prevents multiple pending NetworkDown events?

I think that you should call FreeRTOS_NetworkDown() only once? The idea was that FreeRTOS_NetworkDown() will be called every 3 seconds ( see ipINITIALISATION_RETRY_DELAY ). You don’t have to do this. What does your xNetworkInterfaceInitialise() return? It should only return pdPASS when the network is up, when there is a Link Status, or when WiFi is connected.

Following up on this, I see that part of the problem is perhaps the DHCP server order? In my case the option order coming from the SonicWall is: (53) DHCP Message Type (Offer) (54) DHCP Server Identifier (1) Subnet Mask (51) IP Address Lease Time (3) Router (6) Domain Name Server (255) End So when the Options hit (3) router, ulProcessed >= ulMandatorOptions and processing ends. Comments refer to Subnet, Gateway, and DNS as being non essential, which shouldn’t be baked into the API the way it seems to me.

Perhaps something down the line of ~~~ const uint32_t ulMandatoryOptions = 3ul;

    ...

        case dhcpEND_OPTION_CODE:
            ulProcessed++;
            break;

~~~ Edit: This doesn’t seem to work at the moment

~~~ /* Walk through the options until the dhcpOPTIONENDBYTE byte is found, taking care not to walk off the end of the options. */ pucByte = &(pxDHCPMessage->ucFirstOptionByte); pucLastByte = &(pucUDPPayload[ lBytes – dhcpMAX_OPTION_LENGTH_OF_INTEREST ]); ~~~ What is the purpose of ~~~

define dhcpMAXOPTIONLENGTHOFINTEREST ( 2L )

~~~ ? In this case, it prevents the options walker from hitting the end and grabbing the last option. So in this case, setting this to 0 is the only way the dns settings can be retrieved. I have attached the DHCP pcap.

Bump. Is there a known good reason for having #define dhcpMAX_OPTION_LENGTH_OF_INTEREST ( 2L ) ? Otherwise I’d like to see this patched.