WMC ports will return "ERROR" to all AT commands, except for "AT" itself. So
just provide a custom AT probing logic, which uses "ATE0" instead, and assumes
the port is not an AT port if an error is returned.
NM attempts to set allowed and preferred mode during the connection
process. The plugin x220x does not handle properly when NM request
allowed mode to '2g, 3g' and the preferred mode to 'none'.
This commit attempts to solve the problem described above. When this
situation happens, establish the mode of the modem has 'ANY' (which
seems the safest one) instead of just throwing an error.
Signed-off-by: David Castellanos <dcastellanos@indra.es>
MBM modems will lie about the unlock status just after having sent a
correct PIN or PUK. So, explicitly wait to get in READY state after having
sent the PIN or PUK, before keeping on.
https://bugzilla.gnome.org/show_bug.cgi?id=696702
When the serial port buffer gets full of non-AT garbage during port probing,
we were re-scheduling the next probing step, which is completely wrong, as we
then would be processing the same probing task twice. If we get a buffer full,
just cancel the AT probing cancellable, which would cancel not only the possible
AT probings, but also the custom init if there is any.
Also, make sure that the custom_init() of the plugins out there don't return an
error if the GCancellable is cancelled. Cancelling the GCancellable means we
should just stop the custom_init(), and actually sending an error in
custom_init() means that the port should be set as unsupported by the plugin, so
completely different things.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=696695
The probing logic expects either one or the other right now. In this case, it is
just simpler to include the Nozomi-related VID in the vendor filter, and remove
the product filter.
+CME ERROR: 3 (Not Allowed) means airplane mode, at least for the
Samsung Yxxxx devices that I've got. And if we get this error
on any other devices, chances are they'll fail to power up too.
Plugins which may support QMI ports need to explicitly request QMI probing
in cdc-wdm devices. This should also avoid probing cdc-wdm ports when we know
that the plugin doesn't support them (e.g. with Ericsson MBM devices).
https://bugzilla.gnome.org/show_bug.cgi?id=696701
So do it during port probing. If we send this command early enough in the
first AT port being probed, it should flip the secondary ports to AT mode
before their port probing is finished.
https://bugzilla.gnome.org/show_bug.cgi?id=696696
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.
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.
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
We need to handle modems which appear in low-power mode (e.g. CFUN=4), so
implement a custom check of the power state. We cannot use the default check
as MBM modems use CFUN also for allowed mode handling.
The generic disconnection logic now already handles getting the port fully
closed and a wait time before reopening it, so no need for a custom
disconnection logic any more.
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
Instead of returning 3 variables in connect_finish(), return a single reference
counted struct. This simplifies how the result is built and passed within a
GSimpleAsyncResult to each _finish() method.
This also simplifies the dialling step in the 3GPP connection sequence, as we
can use the same new type.
Instead of a custom modem_init() step in the 'Modem' interface, just add a
sequence of port initialization commands in each port.
While enabling for the first time a non-hotplugged modem, we will issue the
port initialization commands only after having run the enabling_modem_init()
step (i.e. after ATZ usually).
We previously had the modem initialization command merged with some other port
setup commands in the 'modem_init' step of the 'Modem' interface. Instead of
doing this, we now split the logic into two separate steps:
A first 'enabling_modem_init' modem initialization step is to be run just after
the ports have been opened, but only during the first enabling operation, and
only if the modem was not hotplugged. A hotplugged modem is assumed to be
properly initialized already, so no need to ATZ-it. Also, we will now wait 500ms
by default after the modem initialization command has been sent, to let it
settle down.
The second 'modem_init' step will be run during the 'Modem' interface
initialization, and it currently only holds specific setup of the primary and
secondary serial ports. We'll be modifying this logic a bit in the next commits,
so no big deal to have that step name unchanged.
When setting allowed modes, a ",2" crept into the MODODR command when
porting the plugin from 0.6. That shouldn't be there.
When getting allowed modes, 2 is UMTS preferred and 4 is GSM preferred,
which the previous code combined into only UMTS preferred.
HSUPA/HSPA capable devices (ex F5521gw) can report '3' here, which
we'll decide to interpret as HSPA. It might actually be HSDPA + HSUPA,
but whatever...
