Difference between revisions of "OmaDm"

From WebOS Internals
Jump to navigation Jump to search
 
(14 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:
 +
 +
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

Latest revision as of 09: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