Age | Commit message (Collapse) | Author |
|
When we recover from low-power mode without a modem reset, we may need to
re-send the PIN:
(ttyUSB6): --> 'AT+CFUN?<CR>'
(ttyUSB8): <-- '<CR><LF>OK<CR><LF>'
(ttyUSB6): <-- '<CR><LF>+CFUN: 4<CR><LF><CR><LF>OK<CR><LF>'
(ttyUSB6): --> 'AT+CFUN=1,0<CR>'
(ttyUSB6): <-- '<CR><LF>OK<CR><LF>'
(ttyUSB6): --> 'AT+CPIN?<CR>'
(ttyUSB6): <-- '<CR><LF>+CPIN: SIM PIN<CR><LF><CR><LF>OK<CR><LF>'
(ttyUSB6): --> 'AT+CPIN="1234"<CR>'
(ttyUSB6): <-- '<CR><LF>OK<CR><LF>'
The cached SIM PIN will be the last SIM PIN used to unlock the modem.
If, for any reason, sending the cached PIN fails, we'll end up removing the
cache, so that the user doesn't try to enable the modem too many times using
a possible wrong PIN.
If we get PIN-locked after the power-up and we didn't cache any PIN, which may
happen if MM crashes, reboots and the modem was already unlocked (we won't ask
for PIN during initialization), then we'll perform a device reset. This
situation is really a corner case to be handled nicely.
|
|
|
|
Specially the first time that CFUN=1,0 is issued after the initial power up, we
really need to wait more than 3s for the AT command reply. Otherwise, the modem
won't like it and it will reset itself :-/
|
|
Not only +PACSP0, but also +PACSP1.
|
|
There was a missing step++ when falling down to the next step in the switch(),
which was preventing a proper connection.
|
|
|
|
|
|
|
|
The generic plugin should be a fallback, so when starting to probe the port,
never start with the Generic plugin first.
|
|
Update the default timeout from 3s to 10s.
|
|
Every port probing will have the Generic plugin as fallback, and due to some
other issues in other plugins (see ee099fcd), we need to allow overwriting the
suggested plugin from the Generic to a more specific one.
One of the drawbacks of this is that we're actually allowing the Generic plugin
to probe and accept the port, which means that the generic plugin may accept a
specific port type (e.g. QMI) while the specific plugin wouldn't. So, we will
now also run the subsystems filter before grabbing the specific port, in order
to really filter out those cases. We still keep the subsystems filter in
pre-probing, so that we build a better initial plugin list to probe.
|
|
|
|
If an error occurs early during the initialization (e.g. during port setup), we
would be aborting without even having exported the modem interface. So detect
that case and skip setting the modem as valid.
|
|
Plain non-Icera ZTE modems will use ATD calls and PPP to establish the
connection, so ignore 'net' ports that may be found in the way (e.g. when the
modem is a QMI modem and we're not using QMI support).
|
|
Disabled in normal compilation, can be enabled to debug issues.
|
|
The Location property was never being updated properly.
|
|
When the 3GPP location is enabled, we need to reload the operator code
information, but only if the modem is registered in a 3GPP network.
Now, instead of looking at the global modem state value, look at the specific
3GPP registration state. This will avoid issues like:
* updating 3GPP operator info and the modem registered in a CDMA network.
* not updating the 3GPP operator info when the modem is registered in a 3GPP
network but not yet fully enabled (i.e. 'enabling').
|
|
The Bus Pirate v4 presents itself as a CDC ACM device which
ModemManager attempts to configure. This results in a range
of confusing issues because it injects a bunch of AT commands
over whatever is going on at the time.
Firmware updates were failing at random points and avrdude
failed to work at all. Blacklisting it fixed my issues.
|
|
Unfortunately, Sierra secondary APP ports reply to +GCAP with
only "OK", and not their APP port number or model number. So instead
of using +GCAP, we have to use ATI to get secondary port information.
This allows us to detect which port is the APP1 port that we can
potentially use for PPP, leaving the primary port available for
control and status.
Also, some modems have up to 3 or 4 APP secondary ports, which we
need to ensure aren't used as primary. The previous check for +GCAP
handled that, but let's make it more explicit.
AT+GCAP reply:
OK
ATI reply:
Sierra Wireless, Inc.
C885
APP1
OK
See also: 3f3987e09ee762e48c1d53cb42a1288ce9f332cb (MM_06)
|
|
If the primary port is gone (e.g. when going to sleep) and we are just in the
middle of a connection attempt, we won't be able to receive any unsolicited
message regarding the status of the attempt. So, if we detect that the port is
forced to get closed, we'll just treat it as a connection failure.
http://code.google.com/p/chromium-os/issues/detail?id=35391
|
|
Avoids warnings like:
GLib-GObject-WARNING **: gsignal.c:2576: instance `0x78624028' has no handler with id `148'
|
|
|
|
|
|
Turns out older devices (like the C885/AT&T Mercury) crash often
when we don't wait for them to settle from CFUN=1. 5 seconds is
too short, but the crashes go away when we wait for 10 seconds.
Newer modems like the USB306 don't have this problem, so we just
check to see if the modem is a DirectIP device (using sierra_net)
and only use the shorter timeout for those newer devices.
This is a separate problem from some older modems returning ERROR
to valid commands that are sent too soon after CFUN=1, which was
observed on really old devices like the PCMCIA 860.
|
|
|
|
|
|
Some devices prefix the replies with the command, some don't, so
strip off the prefix if it exists.
|
|
|
|
|
|
Assume 2000 + year.
|
|
Unlike strtol/stroul, this function doesn't ignore leading or
trailing non-digit characters, so document that restriction.
|
|
Some Huawei modems report these, and we may use the generic helper
in the future.
|
|
|
|
Parent MMBroadbandModem may not implement these functions so we
shouldn't call them unless it does.
|
|
Many Huawei CDMA modems implement vendor commands for 1x and EVDO
signal quality, so use them since they are more accurate than the
generic signal checking.
(port of a similar patch for MM_06 by heiher <admin@heiher.info>)
|
|
Both CDMA and 3GPP modems emit this, but using slightly different
formats.
|
|
Both CDMA and 3GPP modems use SYSINFO, so consolidate the parsing of
its response.
|
|
We need the kernel driver to give a proper value for the 'closing_wait'
variable, but don't assume it will.
This should solve the following kind of issues reported by valgrind:
==8985== Conditional jump or move depends on uninitialised value(s)
==8985== at 0x4409A6: mm_serial_port_close (mm-serial-port.c:932)
==8985== by 0x41A420: disable_all_done (mm-generic-cdma.c:753)
==8985== by 0x4125A4: mm_manager_shutdown (mm-manager.c:1130)
==8985== by 0x40DE35: main (main.c:203)
|
|
|
|
|
|
|
|
|
|
The 'hso' driver tags Icera-based modems' proprietary protocol port
as a DIAG port, but since they aren't Qualcomm-based, it's not
a DIAG port. Just turn off AT probing and let QCDM probing
fail the port instead of assuming it's a DIAG port.
|
|
If we read a response that indicates the port is definitely not an
AT capable port, stop AT probing. Certain ports that use proprietary
protocols or other non-AT protocols tend to spew data at us, so when
this happens we can cut probing short.
|
|
|
|
If a response processor closed the port, don't try to read any
more data from it. Move the priv->watch_id check to the
while condition so the loop terminates before calling
g_io_channel_read_chars() again, which caused a warning since
the underlying file descriptor was already closed.
Also, bytes_read will never be less than zero (it's unsigned),
so skip the bytes_read > 0 check and just assert that this
condition is true.
|
|
Signal was attached with user_data as MMPortProbe*, but
serial_buffer_full() treated user_data as a PortProbeRunTask*.
Hillarity ensued.
|
|
Sierra devices often have limited AT parsers on their APP ports
which reply with OK to any command they don't understand, and
thus we need to actually check for a valid IPSYS reply instead of
just checking whether the IPSYS request completed without error.
Previously MM would detect Icera capability on devices that
didn't actually have it.
|
|
Bandrich C120 returns BAD_LENGTH rather than BAD_COMMAND, perhaps
because it re-uses the same subsystem number for something else.
|
|
If +CIND fails for any reason (generic failure, wrong indexes, etc) or
reports zero signal strength (quirky modem) then fall back to +CSQ.
|