Difference between revisions of "OmaDm"

From WebOS Internals
Jump to navigation Jump to search
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
== Introduction ==
 +
 
This page will document knowledge about OmaDm.  Note that some previous research of the over-the-wire behaviour of OmaDm has been done at [[Update_Service_Trace]].
 
This page will document knowledge about OmaDm.  Note that some previous research of the over-the-wire behaviour of OmaDm has been done at [[Update_Service_Trace]].
  
Line 14: Line 16:
 
  OmaDm -prepare %X
 
  OmaDm -prepare %X
 
  OmaDm -report_results
 
  OmaDm -report_results
 +
 +
== Working Directory ==
  
 
If you doctor and boot a device with the UpdateDaemon and OmaDm binaries disables, you get the following directory contents:
 
If you doctor and boot a device with the UpdateDaemon and OmaDm binaries disables, you get the following directory contents:
Line 21: Line 25:
 
  system_settings.info (contains localeCountry and localeLanguage settings)
 
  system_settings.info (contains localeCountry and localeLanguage settings)
 
  tmp (empty directory)
 
  tmp (empty directory)
 +
 +
== OmaDm -syncdata ==
  
 
If you run "OmaDm -syncdata", a couple of files appear:
 
If you run "OmaDm -syncdata", a couple of files appear:
Line 32: Line 38:
  
 
The OmaDm binary seems to have support for Sprint, bell, ROW, and Verizon only.  We're not sure whether this is a problem for AT&T or other carrier devices, but we'll assume that it is intentional for the moment.
 
The OmaDm binary seems to have support for Sprint, bell, ROW, and Verizon only.  We're not sure whether this is a problem for AT&T or other carrier devices, but we'll assume that it is intentional for the moment.
 +
 +
Note that while "OmaDm -syncdata" can create the DmTree files from scratch, it gives an error if you run it on files with invalid contents:
 +
 +
[SyncData: 316]: TRG_RDM_init error: 24577
 +
 +
Removing the DmTree.xml file and re-running "OmaDm -syncdata" is enough to regenerate both files.
 +
 +
An strace on "OmaDm -syncdata" shows that it reads the following locations:
 +
 +
/usr/share/omadm/DmTree.xml
 +
/usr/share/omadm/none
 +
/etc/prefs/properties/DMCARRIER
 +
/dev/tokens/DMCARRIER
 +
/etc/prefs/properties/PalmSN
 +
/dev/tokens/PalmSN
 +
/etc/prefs/properties/DMCLoAUTHNAME
 +
/dev/tokens/DMCLoAUTHNAME
 +
/etc/prefs/properties/DMCLoAUTHPW
 +
/dev/tokens/DMCLoAUTHPW
 +
/etc/prefs/properties/DMCLoNONCE
 +
/dev/tokens/DMCLoNONCE
 +
/etc/prefs/properties/DMSVRoAUTHPW
 +
/dev/tokens/DMSVRoAUTHPW
 +
/etc/prefs/properties/DMSVRoNONCE
 +
/dev/tokens/DMSVRoNONCE
 +
/etc/prefs/properties/buildNumber
 +
/etc/palm-build-info
 +
/usr/lib/ipkg/info/*.control
 +
 +
and writes to:
 +
 +
/var/log/omadm.log
 +
/var/lib/software/DmTree.xml
 +
/var/lib/software/DmTree.backup.xml
 +
 +
The /var/log/omadm.log file also shows that OmaDm does a platformQuery and imeiQuery on the com.palm.telephony service to get the platformType, imei, capabilities and version of the cellular subsystem.
 +
 +
An OmaDm binary strings examination shows that /usr/share/omadm/none may be a flag file to disable software updates.
 +
 +
It seems that the /etc/prefs/properties directory can use used to override the device tokens and build information.  This may be handy for other purposes ...
 +
 +
So in general, the DmTree.xml files contain authorisation information, a list of currently installed packages (with a build number for each), and possibly cellular provisioning information (need to check this on a CDMA device).
 +
 +
The template for DmTree.xml can be found in /usr/share/omadm/DmTree.xml and is populated with the information gained from reading all the input data sources.
 +
 +
It seems that "OmaDm -syncdata" is additive, replicating the package-related contents in the DmTree.xml files each time it is called.
 +
 +
== OmaDm -revert_tree ==
 +
 +
At this point, the DmTree.backup.xml and DmTree.xml files are identical.
 +
 +
Experimentation with changing the contents of the files shows that "OmaDm -revert_tree" simply overwrites DmTree.xml with the contents of DmTree.backup.xml.
 +
 +
== OmaDm -set_domain ==
 +
 +
Running "OmaDm -set_domain" results in the following errors:
 +
 +
[RdmInitCarrier: 423]: Unrecognized carrier ATT
 +
[RdmSetDomain: 506]: Unable to open /var/lib/software/domain
 +
[SetDomain: 376]: RdmSetDomain error
 +
 +
The first is spurious. The second and third indicate that a "domain" file is required. Perhaps the UpdateDaemon binary supplies this file.
 +
 +
Creating a "domain" file and then running "OmaDm -set_domain" results in the contents of the "domain" file being used to generate the PalmOMADMAcc.AppAddr.SrvAddr.Addr node contents (with "https://" prepended and "/palmcsext/swupdateserver" appended to it).
 +
 +
Examination of a normal device indicates that the "domain" file normally has the contents "ps.palmws.com" (with no terminating newline character), resulting in a "https://ps.palmws.com/palmcsext/swupdateserver" value in the DmTree.xml files.
 +
 +
The "domain" file is written by UpdateDaemon each time it starts, based on the "locationHost" system preference.
 +
 +
== OmaDm -client ==
 +
 +
Calling "OmaDm -client" updates some authentication values in DmTree.xml and creates the following files in the SessionFiles directory:
 +
 +
client_server.xml
 +
component_list
 +
dmhttps.header
 +
server_client.xml

Latest revision as of 08:27, 8 July 2011

Introduction

This page will document knowledge about OmaDm. Note that some previous research of the over-the-wire behaviour of OmaDm has been done at Update_Service_Trace.

OmaDm seems to be involved in carrier provisioning and webOS OTA updates. Its working directory seems to be /var/lib/software.

It is called from UpdateDaemon, with the following arguments (found by using strings on the UpdateDaemon binary):

OmaDm -syncdata
OmaDm -revert_tree
OmaDm -set_domain
OmaDm -client
OmaDm -task
OmaDm -server
OmaDm -prepare
OmaDm -prepare %X
OmaDm -report_results

Working Directory

If you doctor and boot a device with the UpdateDaemon and OmaDm binaries disables, you get the following directory contents:

ModemFiles (empty directory)
SessionFiles (empty directory)
system_settings.info (contains localeCountry and localeLanguage settings)
tmp (empty directory)

OmaDm -syncdata

If you run "OmaDm -syncdata", a couple of files appear:

DmTree.backup.xml
DmTree.xml

On a Veer, you also get the following error message:

[RdmInitCarrier: 423]: Unrecognized carrier ATT

The OmaDm binary seems to have support for Sprint, bell, ROW, and Verizon only. We're not sure whether this is a problem for AT&T or other carrier devices, but we'll assume that it is intentional for the moment.

Note that while "OmaDm -syncdata" can create the DmTree files from scratch, it gives an error if you run it on files with invalid contents:

[SyncData: 316]: TRG_RDM_init error: 24577

Removing the DmTree.xml file and re-running "OmaDm -syncdata" is enough to regenerate both files.

An strace on "OmaDm -syncdata" shows that it reads the following locations:

/usr/share/omadm/DmTree.xml
/usr/share/omadm/none
/etc/prefs/properties/DMCARRIER
/dev/tokens/DMCARRIER
/etc/prefs/properties/PalmSN
/dev/tokens/PalmSN
/etc/prefs/properties/DMCLoAUTHNAME
/dev/tokens/DMCLoAUTHNAME
/etc/prefs/properties/DMCLoAUTHPW
/dev/tokens/DMCLoAUTHPW
/etc/prefs/properties/DMCLoNONCE
/dev/tokens/DMCLoNONCE
/etc/prefs/properties/DMSVRoAUTHPW
/dev/tokens/DMSVRoAUTHPW
/etc/prefs/properties/DMSVRoNONCE
/dev/tokens/DMSVRoNONCE
/etc/prefs/properties/buildNumber
/etc/palm-build-info
/usr/lib/ipkg/info/*.control

and writes to:

/var/log/omadm.log
/var/lib/software/DmTree.xml
/var/lib/software/DmTree.backup.xml

The /var/log/omadm.log file also shows that OmaDm does a platformQuery and imeiQuery on the com.palm.telephony service to get the platformType, imei, capabilities and version of the cellular subsystem.

An OmaDm binary strings examination shows that /usr/share/omadm/none may be a flag file to disable software updates.

It seems that the /etc/prefs/properties directory can use used to override the device tokens and build information. This may be handy for other purposes ...

So in general, the DmTree.xml files contain authorisation information, a list of currently installed packages (with a build number for each), and possibly cellular provisioning information (need to check this on a CDMA device).

The template for DmTree.xml can be found in /usr/share/omadm/DmTree.xml and is populated with the information gained from reading all the input data sources.

It seems that "OmaDm -syncdata" is additive, replicating the package-related contents in the DmTree.xml files each time it is called.

OmaDm -revert_tree

At this point, the DmTree.backup.xml and DmTree.xml files are identical.

Experimentation with changing the contents of the files shows that "OmaDm -revert_tree" simply overwrites DmTree.xml with the contents of DmTree.backup.xml.

OmaDm -set_domain

Running "OmaDm -set_domain" results in the following errors:

[RdmInitCarrier: 423]: Unrecognized carrier ATT
[RdmSetDomain: 506]: Unable to open /var/lib/software/domain
[SetDomain: 376]: RdmSetDomain error

The first is spurious. The second and third indicate that a "domain" file is required. Perhaps the UpdateDaemon binary supplies this file.

Creating a "domain" file and then running "OmaDm -set_domain" results in the contents of the "domain" file being used to generate the PalmOMADMAcc.AppAddr.SrvAddr.Addr node contents (with "https://" prepended and "/palmcsext/swupdateserver" appended to it).

Examination of a normal device indicates that the "domain" file normally has the contents "ps.palmws.com" (with no terminating newline character), resulting in a "https://ps.palmws.com/palmcsext/swupdateserver" value in the DmTree.xml files.

The "domain" file is written by UpdateDaemon each time it starts, based on the "locationHost" system preference.

OmaDm -client

Calling "OmaDm -client" updates some authentication values in DmTree.xml and creates the following files in the SessionFiles directory:

client_server.xml
component_list
dmhttps.header
server_client.xml