On Sat, 2 Feb 2019 22:28:33 -0800 Michael Forney <mfor...@mforney.org> wrote:
> On 2019-02-02, Sean MacLennan <se...@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
