On Fri, Nov 1, 2013 at 2:01 AM, Patrik Flykt <patrik.fl...@linux.intel.com>wrote:
> > > When you say "system as a whole", that somehow implies that the system > as a whole is going to some form of deep sleep. Are only a selected set > of processes suspended, is the whole user space frozen or the whole > thing including kernel and user space? What is the real use case behind > the lease expiration exporting and can that use case be handled instead > with ConnMan using a specific API in the system instead of implicitely > posting timers? > Have you taken a look at the Session API? As it informs applications of > connections appearing and disappearing, can this be a part of the > solution you are looking for? > > It sounds as there is some kind of a "sleep daemon" in the system that > is triggering system sleep. Can you elaborate more on the sleep > functionality and use cases of the system in question? > > If kernel and wpa_supplicant are suspended, the device will drop off > from the WiFi network after a timeout, and at that point there is > nothing to restore when DHCP should be reacquired. A suspend on a normal > Linux laptop will drop the connections before going to suspend so > ConnMan needs to do a full reconnect on wakeup. Also, if the device or > network moves away, there is nothing to restore either. How are these > issues taken into account? > > > Cheers, > > Patrik > > Hi Patrik, We do indeed have a sleep manager that will put our system to deep sleep/suspend. This sleep manager also uses the RTC to schedule a wake for future tasks. However, the wifi chip we use performs suspend-idle association and is configured with wake-on-WLAN filters to wake the host for certain network traffic addressed to the device. This allows us to keep a consistent association to the network despite the primary processor being asleep. Unless the DHCP lease statistics are known. it's not possible for the sleep manager to schedule wakeups to renew the DHCP lease. If there are no scheduled wakeup events that occur during the renewal period of the lease then we will lose our lease and no longer are woken up by packets addressed to us. Additionally, we don't want to suspend in the middle of a DHCP renewal, and therefore need to be able to query the DHCP state from our client. It doesn't appear that the session api provides this information. For connman clients uninterested in this DHCP state, the "DHCP" dictionary entry in "IPv4" is strictly advisory and informational and should not negatively impact any other connman clients or create any API incompatibilities. Connman clients such as ours, for which this state is critical, can find it and put it to good use to achieve these system availability improvements. Thanks, -Andrew _______________________________________________ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
