Re: [PATCH v2] dhcp: fix overflow causing retries to stop

Hi Denis,

On 1/12/24 9:11 AM, Denis Kenzior wrote:
> Hi James,
>
> On 1/11/24 07:33, James Prestwood wrote:
>> If DHCP is in a SELECTING/REQUESTING state and the number of attempts
>> reached a value where 2 << attempts overflowed an unsigned int the
>> next timeout would become zero, causing DHCP to never retry without
>> any event notification.
>>
>> Roughly 2 minutes has passed when we reach >5 attempts so it makes
>> little sense to retry indefinitely, at least without notifying the
>> upper layers (which could decided to retry themselves).
>
> Okay, but '5' is just a magic number in the code with no context. Lets 
> avoid that.
>
> Can we make this limit configurable?  Say between 3..30?  For iwd, 
> even 2 minutes might be too long.

I'm thinking it may be better to leave the default unlimited retries but 
add a configurable time limit versus retry limit. Setting based on 
retries isn't intuitive a) because 99% of people have no idea what the 
backoff algorithm is, and b) time limits are fuzzed so its not an exact 
amount of time.

I say this because if we want to include netconfig into IWD's Connect() 
DBus method return we kinda need a way to define a time limit as opposed 
to guessing how long 2-3 retries will actually take. We, potentially, 
could iterate through several BSS's and fail extending the time to 
connect, then start DHCP. We would need a way to limit netconfig to 
within the DBus method timeout (25 seconds IIRC), including how long all 
the connect attempts took prior. Maybe I'm overthinking it but 
theoretically we could hit the method timeout limit so we may want to 
add handling for it, which would be easier if we did the above with a 
timeout versus retries.

Thanks,

James

>
> Regards,
> -Denis