Tests had either their own g_print()s or they would enable a _mm_log() method to
get all g_debug()s from the libraries printed. In order to cleanup the result of
the tests run, avoid this stdout dumps by default, and only enable them if
explicitly enabled in CFLAGS, e.g.:
$> ./configure CFLAGS="-DENABLE_TEST_MESSAGE_TRACES"
Some modems do require it, but some others won't (e.g. CDMA based ones), so
just make the operation optional, but only if the modem replies NoDeviceSupport.
https://bugzilla.gnome.org/show_bug.cgi?id=702419
It is quite common to have modems handled with QMI but with very limited
services implemented, e.g. without WMS:
[/dev/cdc-wdm0] QMI Device supports 5 services:
[/dev/cdc-wdm0] ctl (1.3)
[/dev/cdc-wdm0] wds (1.5)
[/dev/cdc-wdm0] dms (1.2)
[/dev/cdc-wdm0] nas (1.0)
[/dev/cdc-wdm0] cat (0.0)
We'll now fallback to use plain AT commands when no QMI WMS service is found.
It sometimes provides a much better view of the supported modes than the WS46=?
command, which is not always properly implemented. E.g.:
Nokia N950:
---------------
at+ws46=?
(12)
OK
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA,HSUPA
OK
Sierra AC313u
---------------
at+ws46=?
ERROR
at*cnti=2
*CNTI: 2,GSM,GPRS,EDGE,UMTS,HSDPA/HSUPA,HSPA+,LTE
OK
We may be asking to load supported modes while in locked state, so the commands
may fail. In order to re-load them properly once we're unlocked, we better just
return an error instead of setting defaults.
We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
Changes being:
* Don't rely on the band preference TLVs presence. The band preference TLVs are
always given, even if the modem doesn't support the specific capability right
away. E.g. a GSM/UMTS/LTE modem configured with 'gsm-umts' capability (no
'lte') still shows the LTE band preference TLV in the SSP responses.
* Don't automatically add LTE as current capability. We needed this when we
were not able to change capabilities, so that we didn't lose the ability to
set 4G mode as allowed.
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
For CDMA-only devices, we will default to IPv4.
For 3GPP devices, we will use the AT+CGDCONT=? test command to query which are
the supported PDP types.
We want to expose in the Modem interface the list of supported IP families, and
the easiest way to do so is to have the IP family as flags, and provide in the
interface a single enum.
Also, a value of 0 for a MMBearerIpFamily specifies that no flags are set, so
just rename it to 'NONE'.
And add a new 'ANY' value which sets all flags to 1.
If the context is already defined, then we can just use it instead
of calling +CGDCONT to create it again. Modems don't like this,
plus it's pointless.
https://bugzilla.gnome.org/show_bug.cgi?id=701151
Some QMI modems seem to fail when requesting to list all SMS messages in a given
storage. When this happens, we'll loop through all storages but performing per
tag list requests.
If the bearer is connected and we get a notification of being unregistered, wait
up to 15s to force the disconnection, in case we can recover the registration
in the meantime.
https://bugzilla.gnome.org/show_bug.cgi?id=699803