Some Icera-based modems (e.g. Samsung/Icera Y3300/Y3400) may take a loong time
to run the power down command (see commit 5f1a1cf8). So, for these modems we
will fully skip the power down command run during initialization.
The power-down command defined by the plugin will be run *only* after having
checked for current and modem capabilities, as plugins (e.g. Sierra) may have
different commands for that depending on whether they are 3GPP or 3GPP2.
We do not reuse the 'modem_power_down' callback from the disabling sequence, as
some plugins really behave pretty badly with this (e.g. Samsung CFUN=4 may take
up to 30s to complete). So, we let plugins use the power-down command when
disabling but avoid launching it during init.
In order to ease the life for clients listening to the 'state-changed' signal,
the change in the 'state' property in the DBus interface skeleton is flushed
right away, before emitting 'state-changed'. By doing this we make sure that
the 'state-changed' callbacks in the clients are able to see exactly the same
current state in the modem proxy.
The `MMManager' is itself also a `GDBusObjectManagerServer'. If we create this
object after having fully acquired the bus name, the client application in the
other side of the bus could be trying to use the ObjectManager interface before
we actually exported it, which is wrong. Therefore, we need to make sure that
the Manager interfaces are all exported before the name is acquired.
The build system sets up this variable for us, so use it rather than
hardcoding "pkg-config" which might be the wrong one.
Equivalent to the one done by
Mike Frysinger <vapier@gentoo.org>
in libqmi.
Some modems report "Unknown" as the operator name when failed to obtain
the actual value:
--> 'AT+COPS=3,0;+COPS?<CR>'
<-- '<CR><LF>+COPS: 0,0,"Unknown",0<CR><LF><CR><LF>OK<CR><LF>'
This patch prevents "Unknown" from being treated as a valid operator name.
Don't rely only in the first grabbed port to get VID/PID. Some modems, e.g.
Huawei E367, won't report a proper VID in the cdc-wdm port, which is the first
one probed.
Some modems, e.g. Huawei E367, will probe first the QMI port and for some reason
it doesn't report a proper VID/PID so the Generic plugin is the one finally
accepting that port. When we probe the AT ports afterwards we already got the
Generic plugin as suggestion, and we end up not grabbing the proper primary and
secondary ports as we skipped the AT^GETPORTMODE reply.
So, from now on the Generic plugin is never suggested to other probes; except
for the case where we need the suggestion to finish a probing task which was
'deferred until suggested'.
Also, the device-level plugin can now be overwritten, if and only if, the
previously set plugin was the Generic one.
Some devices, e.g. ZTE MF820D, seem to prefix the `AT+CGMM?' response with the
`+CGMM:' string, resulting in the following model string being loaded:
model: '+CGMM: "MF820D"'
Avoid this by:
1) Removing the expected prefixes.
2) Unquoting the resulting string.
Reported by: Marius Kotsbak <marius.kotsbak@gmail.com>
When a user creates an SMS object, we will expose all its properties in DBus
properly, but we will not create the internal list of SMS parts.
The list of SMS parts will be created when the SMS is stored or sent, whatever
comes first. When the message is sent and it was previously stored, the list of
parts is not re-created.
If the message requires multiple parts, the multipart reference is computed as
follows:
* If the SMS was not stored and is being sent, we just use a random number.
* If the SMS is being stored, we will use a multipart reference which is not
being used already in another SMS to the same destination.
Usage:
mmcli-test-sms [MODEM INDEX] [all|ucs2|gsm7|data] [NUMBER]"
If [NUMBER] is not given, a dummy number will be used and NO SMS will be sent.
If you give a proper [NUMBER], we will try to send the SMS.
This new action allows creating a new file with the binary data stored in the
SMS, if any.
E.g.:
$> sudo mmcli -s 7 \
--create-file-with-data=output.txt
This action can only be run on SMS object with binary data.
This switch can be run along with the `--messaging-create-sms' action, in order
to include in the SMS the data as given in the file specified by the new switch.
E.g.:
$> sudo mmcli -m 0 \
--messaging-create-sms="number='1234567890'" \
--messaging-create-sms-with-data=file.txt
In this case, the SMS properties string cannot contain a 'text' field.
When receiving an SMS, if the encoding is either GSM7 or UCS2, we will treat the
contents of the SMS as text; and if the encoding is either 8BIT or unknown, we
will just dump the contents of the SMS as data.
When creating an SMS, the user is not allowed to give both text and data, only
one can be given. We will use by default 8BIT when data is given, and guess the
best encoding if text is given.
Note that it's still possible to have SMS with neither text nor data, as in
delivery status reports.
This commit also handles the split of the input data in order to make it fit
into singlepart or multipart messages.
