On Thu, Apr 30, 2015 at 3:48 AM, Patrik Flykt <[email protected]> wrote: > > Hi, > > On Wed, 2015-04-29 at 12:57 -0700, Adam Moore wrote: >> On Mon, Apr 27, 2015 at 8:26 AM, Olivier Pinel (opinel) >> <[email protected]> wrote: >> > Hello, >> > >> > I am facing a random issue with NTP time setup when conman starts. >> > I am using conman 1.27 (will try to reproduce with 1.29 tomorrow) with a >> > single ethernet connection. >> > >> > From my first investigation (I am quite new to conman code), I think there >> > is a race condition. In the failing case, it seems that DHCP response is >> > parsed after ethernet service goes to ready so timeservers are set but >> > timeserver_start has already been called and will not be again until a new >> > state changed. >> > >> > I've managed to catch attached traces where there is one success and one >> > failure. >> > Could you please have a look and tell me if my understanding is correct? >> > If so don’t we need to add a restart of time setup at each modification of >> > timeservers list? >> >> Hi Olivier, >> >> I'm experiencing a similar issue using Connman 1.28. I have a device >> running connman, a switch, and a network with a DHCP server. If I >> attach my device to the switch first, I will get a link local address >> and a transition to the "ready" state for the ethernet service. Then, >> if I attach the switch to the network, connman handles the dhcp lease, >> but no transition out of the ready state takes place, and thus no >> Wispr/online check, and thus no state change handling processing (such >> as NTP) occurs. >> >> Though my scenario is fairly controlled, this is a problem during a >> power outage, where a device and switch power up before a DHCP server >> is available. >> >> I'm still a newbie to the connman code too, but it seems like both of >> our problems would be solved if the state change processing (or just a >> timeserver sync) that occurs upon entry to the ready or online state >> is performed after each dhcp lease, though it might be tricky to do >> this cleanly since the handling code is suppressed if there is a state >> transition from a state to itself. >> >> Any advice on what would be appropriate to do here would be appreciated. > > Thanks for the investigations! See if the patch on the mailing list > fixes your issues.
Thanks Patrik! I tried this, but it didn't have an effect in my scenario - after adding some logging I confirmed I'm falling out of __connman_service_ipconfig_indicate_state where it returns EALREADY because the new state matched the old state - in my case both were READY, so I never make it to the new call. Ill keep playing to see if I can put the timeserver sync call somewhere else or possibly not return early in the READY case. Adam > > Cheers, > > Patrik > > _______________________________________________ > connman mailing list > [email protected] > https://lists.connman.net/mailman/listinfo/connman _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
