Re: [dev][sdhcp] more updates

From: Sean MacLennan <seanm_AT_seanm.ca>
Date: Sun, 3 Feb 2019 11:31:31 -0500

On Sat, 2 Feb 2019 22:28:33 -0800
Michael Forney <mforney_AT_mforney.org> wrote:

> On 2019-02-02, Sean MacLennan <seanm_AT_seanm.ca> wrote:
> > First a question: how portable do we want things? The current sdhcp
> > works only on Linux.
>
> I think that depends on how feasible it is to make it portable without
> relying on a bunch of ifdefs to support different platforms.

Ok. I will see what I can do with minimal ifdefs.

> In terms of timerfd, I think it should be okay to use POSIX timers and
> a self-pipe (like that patch I sent you a while back), but it is kind
> of ugly to have to recreate the timers after the fork. Personally, I
> don't see much value in having sdhcp fork; I always run it with a
> service supervisor.

Actually, what I did was implement timerfd for BSD (not quite ready
yet). I agree that the timerfd code tends to work better on Liunux and
I assume Linux is the 90% case.

I actually use the fork case most of the time. So I would like to keep
it ;)

> CLOCK_BOOTTIME is pretty important for being able to resume from
> suspend, but I'm not sure how portable this is. It looks like OpenBSD
> has it, but not FreeBSD. Maybe this could be an option in a config.h?

Good to know. CLOCK_BOOTIME is easy to redefine to CLOCK_MONOTONIC
where needed.

> > * calctimeout() was dividing the timeout by 2. Not sure why so I
> > removed it. Also, the check for less than 60 seconds would only
> > work if you went back in time to Jan 1, 1970 for the first
> > minute after midnight.
>
> Check the comment for the calctimeout() function. It sets the
> itimerspec passed by the caller to half-way until the expiration of
> the specified timer. The struct itimerspec here specifies a time
> *duration*, not a time instant, so I don't think 1970 has anything to
> do with it.

I don't remember the system I checked on, but at least on that system
the time read back was absolute.... I can check again.

> The function uses timerfd_gettime to determine the duration of time
> left until timer `n` expires, then sets `ts` to half of that duration,
> down to a minimum of 60 seconds. This is what RFC 2131 says to do:
>
> In both RENEWING and REBINDING states, if the client receives no
> response to its DHCPREQUEST message, the client SHOULD wait
> one-half of the remaining time until T2 (in RENEWING state) and
> one-half of the remaining lease time (in REBINDING state), down to a
> minimum of 60 seconds, before retransmitting the DHCPREQUEST message.

Yes, my mistake. I was now taking into account when calctimeout() was
called. I thought it was setting the T1/T2 times... but it is setting
the "no response" timeout.

Any comment on the raw socket for Linux?

Cheers,
   Sean
Received on Sun Feb 03 2019 - 17:31:31 CET