GetNetworkTime sometimes returns empty results

Bug #1329534 reported by Tony Espy
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ofono (Ubuntu)
Fix Released
Low
Tony Espy

Bug Description

The org.ofono.NetworkTime interface is being created properly for rilmodem-based devices, and NITZ messages are being processed, but occasionally the received time is not available, and an empty string is returned in response to a GetNetworkTime method call.

Tested on mako running image u76 with both US T-Mobile and AT&T SIMs.

Tony Espy (awe)
Changed in ofono (Ubuntu):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Tony Espy (awe)
summary: - NetworkTime interface exports properties
+ NetworkTime interface not exporting properties
Revision history for this message
Martti Piirainen (piiramar) wrote : Re: NetworkTime interface not exporting properties

Just checking, is this a misunderstanding of the API? org.ofono.NetworkTime indeed does not expose any properties - but there is a method for retrieving the time, and a signal on a new time. This is what D-Bus introspection gives me:

  dbus-send --system --type=method_call --print-reply --dest=org.ofono /ril_0 org.freedesktop.DBus.Introspectable.Introspect

  <interface name="org.ofono.NetworkTime">
   <method name="GetNetworkTime">
    <arg name="time" type="a{sv}" direction="out"/>
   </method>
   <signal name="NetworkTimeChanged">
    <arg name="time" type="a{sv}"/>
   </signal>
  </interface>

I tested this with two Finnish operators (Sonera and Saunalahti), each one in the UMTS (default) and GSM (forced via 'set-tech-preference' script) radio networks.
  dbus-send --print-reply --system --dest=org.ofono /ril_0 org.ofono.NetworkTime.GetNetworkTime
  dbus-monitor --system interface='org.ofono.NetworkTime'
Both the method call and the signal worked for me in all tests.

Revision history for this message
Tony Espy (awe) wrote :

Yea, my description is a bit off, I'll correct it.

That said, using an US-based AT&T SIM, I'm seeing an empty response to GetNetworkTime. I suspect there may be some kind of race condition. Note, I had confirmed receipt of the NITZ message using OFONO_RIL_TRACE, and also that the core code was being notified via a debug statement.

description: updated
Tony Espy (awe)
summary: - NetworkTime interface not exporting properties
+ GetNetworkTime sometimes returns empty results
Revision history for this message
Tony Espy (awe) wrote :

I can't explain, but somehow this is working for me after we landed the last version of ofono with the nettime code merged into out github trunk.

I'm going to change the Status to FixReleased.

Feel free to comment/re-open if you disagree...

Changed in ofono (Ubuntu):
status: Triaged → Fix Released
Tony Espy (awe)
Changed in ofono (Ubuntu):
status: Fix Released → Confirmed
status: Confirmed → Fix Released
Revision history for this message
Tony Espy (awe) wrote :

While reviewing a pull request related to NetworkTime:

https://github.com/rilmodem/ofono/pull/97

I noticed two things after running a series of reboots and checking network time availability.

1. Occasionally a NITZ message isn't sent to the device after startup. This could be an optimization of rild.

2. In very rare circumstances, it's possible for GetNetworkTime to return a dictionary that lacks MobileNetworkCode or MobileCountryCode. The netttime plugin gets these from netreg, and if the values returned are NULL, then ofono's DBus code ( ofono_dbus_dict_append() ) doesn't append the key/value pair to the dictionary.

Tony Espy (awe)
Changed in ofono (Ubuntu):
status: Fix Released → Incomplete
importance: High → Medium
Revision history for this message
Tony Espy (awe) wrote :

Changed Status back to FixReleased as there's not much we can do code-wise about either problem mentioned in comment #4.

Changed in ofono (Ubuntu):
importance: Medium → Low
status: Incomplete → Confirmed
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.