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)
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.
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.
We can skip additional UTF-8 validity check when parsing operator.
mm_charset_take_and_convert_to_utf8() already does a UTF-8 validity check
internally before returning the string, so it's pointless to do a new one
on the returned string.
Plus, mm_charset_take_and_convert_to_utf8() may really return NULL, which
would end up in segfaulting as g_utf8_validate() expects always a non-NULL
string.
Based on 219424a6e2d017491a05ecbed661bccde3f991ef (MM_06 branch)
It appears that GIOChannel might also do some flushing, so make sure
our warning captures that delay if there is one. Also be paranoid
and make sure nothing reset our closing_wait value.
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).
For each port, we will construct the list of plugins to test with. In that list
we will include those plugins which are likely to handle a given port, so we
will skip all those which aren't.
To see if a plugin is likely or not, we will run the pre-probing filters before
adding them to the list, with the new `mm_plugin_discard_port_early()'. This
method will return one of these hints:
* UNSUPPORTED: The plugin will not be able to handle this port.
* MAYBE: The plugin may handle this port.
* LIKELY: The plugin may (very likely) handle this port.
* SUPPORTED: If any plugin should support the port, this is it.
Plugins reported to be 'likely' supporting the port will be probed before the
ones reported just as 'maybe'.
If a plugin reports 'supported' only that one and the fallback generic ones will
be tried.
Logging which are the reasons for a plugin to filter a given port really help
when trying to debug user issues. Some other general logging improvements also
done.
It is not the Modem interface the one notifying about the 'enabling->enabled'
transition, it's the BroadbandModem directly doing it, covering all the enabling
sequences of all the interfaces.
It is not the Modem interface the one notifying about the 'disabling->disabled'
transition, it's the BroadbandModem directly doing it, covering all the
disabling sequences of all the interfaces.
If the modem is currently disabling, we need to wait to get fully disabled
before starting with the new connection sequence.
If the modem is currently disconnecting, we need to wait to get fully
disconnected before starting with the new connection sequence.
Before the change, the client application loses all new property change
notifications in the interface object:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
After the change, it doesn't:
$ sudo mmcli -m 0 -w
/org/freedesktop/ModemManager1/Modem/0: Initial state, 'locked'
/org/freedesktop/ModemManager1/Modem/0: State changed, 'locked' --> 'initializing' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'initializing' --> 'disabled' (Reason: None or unknown)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabled' --> 'enabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'enabling' --> 'registered' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'registered' --> 'disabling' (Reason: User request)
/org/freedesktop/ModemManager1/Modem/0: State changed, 'disabling' --> 'disabled' (Reason: User request)
In QMI modems the logic behind supported and current bands is completely
separated in different services (DMS vs NAS). Actually, the list reported by NAS
as current band preferences seems to include more values than the ones reported
by DMS as supported bands (e.g. CDMA bands are reported even if the firmware
image is GSM/HSPA only).
So, just clean up the list of current preferred bands so that no more than those
given as supported is used.
