All Sierra devices appear to require short delay after powering up,
otherwise subsequent commands may return errors. Older devices need
longer so ensure new devices are penalized just for being new.
This is the port to git master of the following commit, for which we
don't need to do #2:
commit 814febe1fd9baacdb33c79f11c140187df36c4f1
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Oct 30 16:16:25 2012 -0500
sierra: fix CFUN power up delay handling
1) all Sierra devices appear to require short delay after powering up,
otherwise subsequent commands may return errors. Older devices need
longer so ensure new devices are penalized just for being new.
2) When the modem is already in full functionality status and no power
up command was sent, there's no need to delay, which was happening
regardless of what state the modem was already in. Detect whether
the power up was actually executed (response and error will be NULL)
and only delay if it was executed.
+CNUM may return ERROR when the modem fails to read the own numbers from
the SIM card or when the SIM card hasn't been activated. Use $NWMDN to
read the MDN as a fallback, which distinguishes these two cases.
We will not report 'CS' as a supported mode every time '2G' is supported. This
actually was forcing all plugins to handle a 'CS' fallback when they didn't have
CS-specific mode setup. So, to simplify things, we will only report 'CS' as
supported for those plugins which actually allow to select 'CS' mode (e.g. the
'wavecom' plugin).
After repeated stress tests on a few Novatel E362 modems and SIM cards,
it is revealed that a 3-second wait after SIM unlock is necessary for
reliably reading ICCID and IMSI through the SIM interface.
Some Sierra modems trigger a reset of the modem when sending +cfun=1.
All sierra modems supports a second parameter to indicate that no
reset is to be done: "+cfun=1,0".
If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
Tries to fix https://bugzilla.gnome.org/show_bug.cgi?id=685578
The $NWQMISTATUS command sometimes replies an ERROR shortly after
calling the $NWQMICONNECT command, but then replies the proper QMI
status if we retry it. This behavior is observed on an E362 modem with
4.08 firmware.
(ttyUSB0): --> 'AT$NWQMICONNECT=,,,,,,"",,,"",""<CR>'
(ttyUSB0): <-- '<CR><LF>OK<CR><LF>'
(ttyUSB0): --> 'AT$NWQMISTATUS<CR>'
(ttyUSB0): <-- '<CR><LF>ERROR<CR><LF>'
Got failure code 100: Unknown error
QMI connection status failed: Unknown error
In firmware 4.08, the $NWQMISTATUS command returns different values for
QMI state to indicate the current connection state. This patch modifies
the code to handle $NWQMISTATUS responses in firmware 1.41 and 4.08.
This reverts commit e2f3034f6e.
The report of current access technologies is supposed to give which is the
*current* access technology being active. We allow reporting more than one for
the cases where several access technologies are given simultaneously (e.g.
cdma1x + evdo + lte). For example, we shouldn't be giving 4 different
technologies like "umts, hsdpa, hsupa, hspa" when the modem reports
"3G-HSDPA-HSUPA". Just giving HSPA in that case is enough and more accurate.
This WWAN module came installed in my new HP EliteBook 8570p Laptop.
The patch is generated against the master branch but the same udev
rule should be useful in the 0.5 and 0.6 branches as well.
Signed-off-by: David Härdeman <david@hardeman.nu>
This is the port to git master of the following commit:
commit ff8c60641aa2ea41080c15f81f633b3f78e07bf8
Author: Dan Williams <dcbw@redhat.com>
Date: Mon Sep 10 17:12:38 2012 -0500
via: new plugin for CBP7-based CDMA and EVDO devices (bgo #683525)
The Via baseband is used in a number of CDMA/EVDO devices, from
ChinaTelecom USB sticks, to the Fusion Wireless/UBlox 2770p, to
various Motorola Android phones.
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
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.
Instead of letting the plugins specify a default storage to use, just look at
the supported ones and use the best one.
"MT is preferred over "ME" or "SM", as "MT=ME+SM"
There is no point in specifying a default 'mem1' memory storage, which is used
for reading/listing/deleting, as those are operations that need a specific
'mem1' set each time.
Also, there is no point in specifying separate default 'mem2' and 'mem3' memory
storages, specially because now we allow Sms.Store() to specify a storage.
So, we will now only have a 'default' memory storage, which is applicable for
both 'mem2' and 'mem3' (storing, sending from storage and deleting).
For those who don't care about the QMI support through libqmi-glib, or if you're
stuck with glib 2.30 (libqmi-glib requires 2.32), this configure switch allows
disabling the QMI support completely.
The logic to detect cdc-wdm ports is still in place, but the QMI probing is
never launched at them. Also, all QMI-related objects won't be compiled.
AT!SELRAT=?
!SELRAT: Index, Name
00, Automatic
01, UMTS 3G Only
02, GSM 2G Only
03, Automatic
04, Automatic
05, GSM and UMTS Only
06, LTE Only
07, GSM, UMTS, LTE
