+TCP DHCP questions

Kernel
1

friesen wrote on Friday, October 05, 2018:

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

2

rtel wrote on Friday, October 05, 2018:

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

3

friesen wrote on Friday, October 05, 2018:

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

4

friesen wrote on Friday, October 05, 2018:

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: m2m_wifi_connect 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

5

friesen wrote on Thursday, October 18, 2018:

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.

6

friesen wrote on Thursday, October 18, 2018:

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

7

heinbali01 wrote on Friday, October 19, 2018:

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.

8

friesen wrote on Monday, October 22, 2018:

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.

9

friesen wrote on Monday, October 22, 2018:

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

10

friesen wrote on Monday, October 22, 2018:

		/* Walk through the options until the dhcpOPTION_END_BYTE 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 dhcpMAX_OPTION_LENGTH_OF_INTEREST		( 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.

11

friesen wrote on Monday, October 29, 2018:

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