If the modem has specific access technology checks, don't override them
with the generic access technology from +CGREG responses, since that
doesn't have the granularity that specific checks do. For example, the
+CGREG response only indicates UMTS, and cannot indicate HSDPA, HSUPA,
HSPA, HSPA+, DC-HSPA, etc.
+GSN response differs widely between modems. Some prefix the
MEID and/or ESN with 0x, some have leading zeros, some return the
MEID and the ESN, and some append the serial number to the end of
the IMEI. Handle that and make the ESN, MEID, IMEI, and
EquipmentIdentifier parsing consistent.
This is the port to git master of the following commit:
commit 294a91d9f6390d532399be35ddbf6a2b8d136576
Author: Thomas Bechtold <thomasbechtold@jpberlin.de>
Date: Mon Mar 25 14:28:03 2013 +0100
sms-utils: use correct printf modifier for gsize
Older devices may crash if asked to connect right after sending the
PIN and unlocking the SIM; they simply stop responding to AT commands
around the first request for access technology and then reboot. A
delay seems prevents this behavior.
Since it's not uncommon to require a delay after SIM unlock, add one
for newer sierra_net devices as well, even though we're not quite
sure if they need one or not. It doesn't hurt, at least.
'result' may be NULL even if no error is set. Errors aren't set
because we want to continue the !TIME/!SYSTIME sequence regardless
of errors, so we can figure out which command the modem supports.
Trying to get a uint32 out of a NULL GVariant makes glib complain,
and it's wrong, so don't do that.
Just remove the last element with NULL strings in the array of errors, as we're
safe using G_N_ELEMENTS() to iterate it.
Reported by Jose Maria Gonzalez Calabozo <jmgonzalezc@indra.es>
While the QCDM and DIAG_NV are the same, in reality they shouldn't
be and there should be a mapping between them. That wasn't happening,
so fix that up and add a few missing modes to the NV item defines.
QMI modems without SIM may report 'UimUninitialized' QMI protocol errors, so
catch those and use them as 'SIM failure' so that they get reported to the user.
We can just tag the ttys instead of the parent usb device, so that the core
logic which looks in the plugin-specified port tags works properly. There is no
need to explicitly tag the net port, as the probing for this port ends when a
plugin suggestion comes from another port probing on the same device.
This patch changes MMIfaceModem3gpp to differentiate between deferrable
and non-deferrable 3GPP registration state updates. Periodic or
unsolicited registration state updates are deferrable, while internal
updates, e.g. due to modem being disabled, are non-deferrable.
Don't clear the current deferred registration update until having disabled
and cleaned up unsolicited registrations state messages, or we may end up
re-setting the deferred registration update again meanwhile
If the rules to tag specific USB interface numbers only apply on the PID, we'll
end up seeing that if the port has a parent with another PID, and that other
PID also has a rule, port will get tagged multiple times. Easier to see with an
example:
The ZTE MF637 (VID 0x19D2, PID 0x0121) had the following rules:
ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"
In our ZTE rules we also have some for the device with PID 0x0002, like:
ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"
And it seems that we can grab multiple PIDs from a single port, i.e. from the
parent objects in the hierarchy:
udevadm info -a -n /dev/ttyUSB4 | grep idProduct
ATTRS{idProduct}=="0121"
ATTRS{idProduct}=="0020"
ATTRS{idProduct}=="0002"
Where that 0x0002 idProduct is not from the modem, but from the EHCI Host
Controller (with idVendor 0x1d6b in my case).
So... we end up seeing that both set of rules will apply to the ports, and we
misleadingly get:
(ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB2' flagged as primary
(ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB1' flagged as secondary
(ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB4' flagged as primary
b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 at (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 data (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm
Which is wrong, as ttyUSB4 should have been our primary port, not ttyUSB2.
With this patch on, the rules apply only to the VID/PID pair, and we end up
getting what we really wanted:
(ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB1' flagged as secondary
(ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB4' flagged as primary
b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 at (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 data (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm
https://bugzilla.gnome.org/show_bug.cgi?id=694759
Allow mm_iface_modem_update_state() receive 'MM_MODEM_STATE_FAILED', and treat
it as any other change to failed state, but with
'MM_MODEM_STATE_FAILED_REASON_UNKNOWN'.
