[Galaxy S II Q&A, Help & Troubleshooting] E:V:A:
Thanks for trying that. Here is a fairly nice description of the Android IPC

protocol from EE times: http://www.eetimes.com/electronics-news/4083262/Google-Android-IPC-at-the-lowest-levels

[EDIT] See post below (#26).

+ For a very nice general introduction to UNIX IPC (non-specific) programming,

see the Brian Hall's: http://beej.us/guide/bgipc/output/html/singlepage/bgipc.html

---

However, the article is from 2009 with focus on the Qualcomm MSM 7200

chip, so I don't know how valid it is for us...

At this point I'm ready to give up on this, it has taken me too much time,

and I don't feel I've gotten anywhere on this. I've posted just about

everything I know about this, but I still haven't found a different way to

communicate with the modem, that is outside the boundaries of the API.

The main motivation for all this, was to be able to read the L1 (radio HW)

variables in real time from the modem. This can be extremely useful, since

the radio API function calls are often buggy, and with too high latency, if

working at all. (For example SignalStrength is not working properly in <GB

2.3.6, but it is working in ServiceMenu, which I know uses a different

interface to get to those variables.) Most of these radio variables are not

even accessible from API.

The amount system programming skills required for this is really way

beyond my talent. So there is little more I can do at this point, without any

radical changes or insight in the availability of simple tools needed to do

this.

I think the key to all this, is understanding: libsec-ril.so, running a

simple strings on this, indicates that it contains all the tools and

information needed. For example, a few interesting strings:

Samsung RIL(IPC) v2.1 [Extracted from ICS 4.0.3, Galaxy Nexus]

broadcast -a com.android.samsungtest.RilCommand --es COMMAND 0C000300000101ffff11470002b0
---
Samsung RIL(IPC) v2.0 [SGS-2, GB 2.3.4]

broadcast -a android.intent.action.CALL_DIAG_OUTGOING -n com.sec.app.RilErrorNotifier/.PhoneErrorReceiver -d %s
broadcast -a android.intent.action.CLOSE_SETUP_WIZARD
broadcast -a android.intent.action.CSC_COMPARE
broadcast -a android.intent.action.CSC_MODEM_SETTING --es MODE COMPARE_VERIFY_MODEM
broadcast -a android.intent.action.CSC_MODEM_SETTING --es MODE SET_LOCK_INFO
broadcast -a android.intent.action.ENABLE_SETUP_WIZARD
broadcast -a android.intent.action.FACTORY_SIM_INSERTED
broadcast -a android.intent.action.INPUT_KEY_EVENT --es KEYCODE 03 --es KEYHOLD 00
broadcast -a android.intent.action.MULTI_CSC_CLEAR
broadcast -a android.intent.action.NO_SIM_NOTY -n com.sec.app.RilErrorNotifier/.PhoneErrorReceiver
broadcast -a android.intent.action.SIM_INIT_CRASH
broadcast -a android.intent.action.SIM_INIT_CRASH -n com.sec.app.RilErrorNotifier/.PhoneErrorReceiver
broadcast -a android.intent.action.SMS_FDN_RESTRICTED -n com.sec.app.RilErrorNotifier/.PhoneErrorReceiver
broadcast -a android.intent.action.WB_AMR --ei EXTRA_STATE %d
broadcast -a com.android.samsungtest.DGS_UniqueNumber -e UniqueNumberKey %s
broadcast -a com.android.samsungtest.LoopbackTest -e STATUS %d
broadcast -a com.android.samsungtest.LoopbackTestPath -e PATH %d
broadcast -a com.android.samsungtest.RilCommand --es COMMAND
broadcast -a com.android.samsungtest.RilDFTCommand --es COMMAND
broadcast -a com.android.samsungtest.RilMISCCommand --es COMMAND
broadcast -a com.android.samsungtest.RilOmissionCommand --es COMMAND
broadcast -a com.samsung.intent.action.PB_SYNC
broadcast -a com.sec.android.app.factorytest --es COMMAND
...
IPC debug port disconnected.
IPC debug port opened.
IPC packet from debug port: mode %d main 0x%02X sub 0x%02X len %d dir %d
...

The ones starting with "broadcast" are really "am" commands that can be

sent directly from terminal. What is interesting is the great flexibility in this

command. It seem that you can send all sorts of commands to pretty

much any application. In addition to these there are:

>240 request* commands

354 IPC_* commands

So having a piece of source code of this would have been heaven, but just

being able to reverse a very few of these requests would probably suffice

in understanding how this works. Unfortunately I don't have the skills for

doing this...

Finally I looked at /system/bin/drexe and found several other AT commands

embedded, most likely interpreted by drexe. I updated post #3 with this list...

However, there were other interesting strings in there, such as:

Remove android adb module
rmmod g_android_adb
system call for rmmod android_adb returned [%d]

Insert serial usb module
insmod /lib/modules/g_serial.ko use_acm=1
system call for insmod g_serial returned [%d]

Inside cancellation cleanup handler
/sys/devices/platform/s3c2410-i2c.5/i2c-5/5-0066/max8997-muic/usb_sel
Opening of the usb select file failed fd is %d & errno is %d
/sys/devices/platform/s3c2410-i2c.5/i2c-5/5-0066/max8997-muic/usb_state

Path set is DATA_PATH_CHAR_MODEM
Path set is DATA_PATH_DR_DEVICE_MANAGER
Path set is DATA_PATH_MODEM
Path set is DATA_PATH_NOT_DEFINE
Path set is DATA_PATH_SMD

broadcast -a android.intent.action.DATA_ROUTER_DISPLAY -n com.sec.app.RilErrorNotifier/.PhoneErrorReceive
InvokeOemRequestHookRaw %s OK
+DISSTRNO:0,OK
InvokeOemRequestHookRaw %s fail %d
+CME ERROR:NG