v4: modems/providers may not return DNS servers and not all modems
support DHCP, so lack of DNS servers should not indicate a bearer
IP method of "DHCP". IP config daemon/scripts already have to handle
missing DNS anyway.
v6: IPv6 requires SLAAC or DHCPv6 as part of the specification, so for
now we assume modems will support it. Provide all the info the modem
sent, but if there is any missing information use an IP method of
"DHCP" to indicate that info should be obtained via SLAAC/DHCPv6. Only
use an IP method of "STATIC" when all basic properties are given by
the modem.
The "0" case wasn't being handled properly:
$ sudo mmcli -m 0 --create-bearer="apn=,allow-roaming=0"
Error parsing properties string: 'Cannot get boolean from string '0''
When we were completing tasks in idle, the logic was like this:
* Schedule task completion in idle
* self->priv->task = NULL
* (idle) Task completion callback called
This meant that the self->priv->task was always set to NULL before the
completion callback was called, which is what we wanted as a new task may be
scheduled in the callback itself.
Now, without completing in idle, we were wrongly doing:
* Task completion callback called
* self->priv->task = NULL
This commit fixes the logic by making sure self->priv->task = NULL before any
task completion.
Initialized "cgmi_retries" variable from CustomInitContext with the
same value as the other retries, moreover the context is now allocated
with g_slice_new0.
Before this changes, when cgmi_retries assumed big values during the
probing of no AT-capable ports, the command AT+CGMI (mm-plugin-dell.c:custom_init_step)
was sent a semi-infinite number of times, blocking the plugin's initialization.
The options that require an argument should explicitly specify so.
Before:
--log-level=INFO Log level: one of [ERR, WARN, INFO, DEBUG]
--log-file Path to log file
After:
--log-level=[LEVEL] Log level: one of ERR, WARN, INFO, DEBUG
--log-file=[PATH] Path to log file
mm-modem-oma.c:400:51: error: implicit conversion from enumeration type 'MMOmaSessionType' to different enumeration type 'MMOmaFeature'
[-Werror,-Wenum-conversion]
g_return_val_if_fail (MM_IS_MODEM_OMA (self), MM_OMA_SESSION_TYPE_UNKNOWN);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/glib-2.0/glib/gmessages.h:382:11: note: expanded from macro 'g_return_val_if_fail'
return (val); \
~~~~~~ ^~~
This should be MMOmaFeature, not MMOmaSessionType. The end result is the same,
as both are 0.
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create' -> (<code class="function">mm_modem_voice_create()</code>).
html/MMCallProperties.html:141: warning: no link for: 'mm-modem-voice-create-sync' -> (<code class="function">mm_modem_voice_create_sync()</code>).
html/MMModemVoice.html:379: warning: no link for: 'mm-modem-voice-delete-finish' -> (<code class="function">mm_modem_voice_delete_finish()</code>).
html/MMModemVoice.html:380: warning: no link for: 'mm-modem-voice-delete-sync' -> (<code class="function">mm_modem_voice_delete_sync()</code>).
make distcheck runs a build in dist directory subtirs and then runs intltool -m
which in turn complains about translations in a built file:
The following files contain translations and are currently not in use. Please
consider adding these to the POTFILES.in file, located in the po/ directory.
sub/data/org.freedesktop.ModemManager.policy.in
The issue is reported to intltool upstream already:
https://bugs.launchpad.net/intltool/+bug/1117944
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The plugins build rules are also updated so that whenever a plugin has some
testable 'helpers', these are compiled into a noinst library and then the new
library included by both the plugin and the tester program. This avoids multiple
recompilations of the same sources for different objects.
We try to combine in common envvars the compiler and linker flags shared by the
different components, and where possible, also re-using the implicit AM_CFLAGS
and AM_LDFLAGS variables that automake provides, and which apply to all objects
being built in the same Makefile.am.
The internal libmodem-helpers.la library is also renamed to libhelpers.la
The rule with multiple targets means that for each of the target the command
specified is run; not that a single run of the command generates all the targets
specified.
So, generate the .c file with the command, and make the .h and the .xml files
a side-effect of the .c generation.
Otherwise:
configure.ac:86: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and its use is discouraged.
configure.ac:86: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' macro instead,
configure.ac:86: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your Makefile.am files.
For non-QMI/non-MBIM Huawei devices that use HiSense chipsets,
the recommended way to create the connection is to use NDISDUP
and either DHCP on the net interface, or the ^DHCP command.
There are some reports of devices that connect successfully, but
don't respond to DHCP requests on the interface. Try to get
IP addressing info from the device via ^DHCP and fall back to
telling clients to use actual DHCP if that fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1254886
Port serial command completions may be performed in several different places:
* When a cached response is set during command sending.
* When errors happen during command sending.
* When we process a response (i.e. common_input_available())
* When we process a timeout (i.e. port_serial_timed_out())
* When cancelled (i.e. port_serial_response_wait_cancelled())
We're currently safe with the previous logic only because the users of the
serial port explicitly complete operations in idle, which means that whenever
we're processing in a internal callback (e.g. during response or timeout
processing) the serial port object is valid for as long as the callback runs.
But, if we ever end up using the serial port with a not-in-idle completion,
it may happen that if the command is completed within a internal signal callback
the serial port object may get fully closed and unref-ed before exiting the
callback.
We could force a valid port reference to exist as long as the internal signal
is scheduled, but then we may lose the ability to automatically close the port
during a full unref(), as the internal signals are set as long as the port is
open.
So, to cope with this possibility of not-in-idle completion, we instead force
references to be valid whenever we see that a command completion may happen,
which is basically whenever port_serial_got_response() is called; but we only
do that if we're going to use the port object after that, otherwise, we ignore
the problem.
In addition to the problems with the references, we also update the
common_input_available() method so that the source isn't kept if the last
response buffer processing ended up closing the port.
Daniele Palmas
Dan Williams
Aleksander Morgado
Carlo Lobrano
Tomas Jura
Brian Norris
Lubomir Rintel
poma