Is there a good way to have a seamless retry on DHCP? The stack calls vIPNetworkUpCalls and sets a default address, then immediately resets the IP to 0 on an eAnswer of eDHCPContinue. This is a bit hard for downstream network threads to detect that it is still trying DHCP. Edit: I was restarting this in my application, so wasn’t really correct.
@@ -444,11 +444,6 @@
/* Is it time to send another Discover? */
else if( ( xTaskGetTickCount() - EP_DHCPData.xDHCPTxTime ) > EP_DHCPData.xDHCPTxPeriod )
{
- /* It is time to send another Discover. Increase the time
- * period, and if it has not got to the point of giving up - send
- * another discovery. */
- EP_DHCPData.xDHCPTxPeriod <<= 1;
-
if( EP_DHCPData.xDHCPTxPeriod <= ( TickType_t ) ipconfigMAXIMUM_DISCOVER_TX_PERIOD )
{
if( xApplicationGetRandomNumber( &( EP_DHCPData.ulTransactionId ) ) != pdFALSE )
@@ -503,6 +498,11 @@
}
#endif /* ipconfigDHCP_FALL_BACK_AUTO_IP */
}
+
+ /* It is time to send another Discover. Increase the time
+ * period, and if it has not got to the point of giving up - send
+ * another discovery. */
+ EP_DHCPData.xDHCPTxPeriod <<= 1;
}
else
{
Basically move the update to the variable after the test has been done?
Let me know if that works for you.
Thanks
P.S., this is a git diff, please make sure that you put the changes in correct location
Isn’t that still going to delay the complete discover period? The problem gets more pronounced the longer it delays, so that the last delay is always pointless after a 1 second or so.
Some things I wonder, perhaps dhcp should be more flexible. Right now its a bit hard to make it act like windows for example, where it autoconf’s, then continues to try dhcp periodically, yet without setting the IP to 0.
Things I have considered:
#1 Allow a total ticks timeout instead of timeout when xDHCPTxPeriod>=ipconfigMAXIMUM_DISCOVER_TX_PERIOD
#2 Allow user defined period shifting instead of EP_DHCPData.xDHCPTxPeriod <<= 1
#3 Use eAnswer from last eDHCPPhaseFailed hook call to restart dhcp without starting the network and setting default addresses.
Apologies, I did not understand you problem statement correctly. Are you trying to get around the problem of longer delays? Or are you saying that the last delay should be cut short if the DHCP server has not responded within a given timeframe?
Would you mind clarifying your issue more?
As for your suggestions, they all sound wonderful. If you have the changes, would you like to create a PR for that?
On a network power cycle (which would include the freertos device)it is very likely that the router won’t be dhcp ready for at least 1 minute.
If I set the ipconfigMAXIMUM_DISCOVER_TX_PERIOD to 120000 ticks, here is the time sequence.
xDHCPTxPeriod
Total ticks
1000
1000
2000
3000
4000
7000
8000
15000
16000
31000
32000
63000
64000
127000
128000
255000
So in this case, the last real try happened at 127000 ticks, but then the dhcp handler goes into lala land for another wasted 128k ticks, when I’d rather it time out and fail.