Understanding the MTK GSM mux daemon

[E3V3A]

If we wanna play with RIL and rild on any device, we need to better understand how to use the MUX as part of the AP-BP communication of AOS. In this case we'll discuss the use of the MTK specific (?) binary: /system/bin/gsm0710muxd and what it is used for. The documentation related to this binary (as it's name suggests) are found in the 3GPP document:

3GPP ETSI TS 101 369 (aka. TS 07.10 v7.2.0) "Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol"

In summary:

The 07.10 multiplexer protocol operates between an MS and a TE and allows a number of simultaneous sessions over a normal serial asynchronous interface. Each session consists of a stream of bytes transferring various kinds of data; for instance, voice, fax, data, SMS, CBS, phonebook maintenance, battery status, GPRS, USSD etc. This permits, for example, SMS and CBS to be transferred to a TE when a data connection is in progress. Many other combinations are possible including digital voice. It is, for instance, possible to transfer digital voice in combination with SMS. The multiplexer allows a complete system to be partitioned in a flexible way between a MS and TE. ... The multiplexer is based on a control channel. On this channel, management information is exchanged, such as parameter negotiation, power saving control information, testing, flow control, close down etc. The multiplexer is optional, but when supported, it is activated with the 07.07 AT+CMUX command. ... Each channel between TE and MS is called a Data Link Connection (DLC) and is established separately and sequentially. Each DLC may have individual flow control procedures for buffer management purposes and the aggregate link also has overall flow control mechanisms. ... The multiplexer has three operating options, basic, advanced without error recovery and advanced with error recovery.

How is this of interest to us? It is not really, but on some MTK devices the ATCoP interface locks up in a weird state, where every character is echoed to radio logcat. This is probably due to not properly closing down the MUX connection after use. Killing the process, resolves the issue, but not the cause. So one possible solution is to use the AT+CMUX= (TBD) command to close the channel. This need testing.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[E3V3A]

Here's the usage options for /system/bin/gsm0710muxd:

# /system/bin/gsm0710muxd -h
        Usage: /system/bin/gsm0710muxd [options]
Options:
        -d: Fork, get a daemon [yes]
        -v: Set verbose logging level. 0 (Silent) - 7 (Debug) [6]
        -s <serial port name>: Serial port device to connect to [/dev/ttyC0]
        -t <timeout>: reset modem after this number of seconds of silence [0]
        -P <pin-code>: PIN code to unlock SIM [-1]
        -p <number>: use ping and reset modem after this number of unanswered pings [0]
        -b <baudrate>: mode baudrate [115200]
        -m <modem>: Mode (basic, advanced) [advanced]
        -f <framsize>: Frame size [1509]
        -n <number of ports>: Number of virtual ports to create, must be in range 1-31 [2]
        -o <output log to file>: Output log to /tmp/gsm0710muxd.log [no]
        -h: Show this help message and show current settings.

The defaults are shown in [...]'s. So this might also be used to increase loglevel and output the log to a file.

I also found some sources for this binary, apparently for the P7100. And the devices used by it are shown here:

#ifdef MTK_RIL_MD1
{ 1, 512, "/dev/radio/pttycmd4" }, /* ALPS00337548 split data and nw command channel */
{ 2, 512, "/dev/radio/pttynoti" },
{ 3, 512, "/dev/radio/pttycmd1" },
{ 4, 512, "/dev/radio/pttycmd2" },
{ 5, 512, "/dev/radio/pttycmd3" },
{ 26, 512, "/dev/radio/atci1" },
#ifdef __ANDROID_GEMINI_SUPPORT__
{ 6, 512, "/dev/radio/ptty2cmd4" }, /* ALPS00337548 split data and nw command channel */
{ 7, 512, "/dev/radio/ptty2noti" },
{ 8, 512, "/dev/radio/ptty2cmd1" },
{ 9, 512, "/dev/radio/ptty2cmd2" },
{ 10, 512, "/dev/radio/ptty2cmd3" },
{ 27, 512, "/dev/radio/atci2" },
#endif
#ifdef __ANDROID_VT_SUPPORT__
{ 24, 512, "/dev/radio/pttyvt" },
#endif

[SecUpwN]

On my current device, the HTC One M7, the binary located in /system/bin/ is obviously called qmuxd since this is the only file with a similar naming. Executing /system/bin/qmuxd -h does not show any output or options. Is there a way of checking if it is indeed the correct binary? I uploaded it for you here.

[E3V3A]

You don't have an MTK device, so don't worry about it.