| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
It modifies the applied connection using the Reapply API.
|
| |
|
|
| |
It makes sense to modify the applied connection from the device object.
|
| |
|
|
| |
Useful with connect, disconnect, delete, monitor, show and reapply.
|
| |
|
|
|
| |
Parsing a single device name from the command line is generally
useful. Remove the open coded versions in reapply, connect & status.
|
| |
|
|
| |
It will look nicer when we have get_device().
|
| | |
|
| | |
|
| |
|
|
| |
It's a semaphore, not a boolean.
|
| |
|
|
|
|
| |
For "nmcli d modify" we'll need to do the completion from async
handlers. This seems to be the most reasonable place to ignore the
errors.
|
| |
|
|
| |
Some functions that take device lists use plural form in name.
|
| |
|
|
|
| |
Completing the property when we stop parsing due to error is not the
right thing to do.
|
| |\
| |
| |
| |
| | |
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00085.html
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00089.html
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoids the following error when ofono isn't running:
NetworkManager[25133]: <info> [1466186144.1392] ofono is now available
NetworkManager[25133]: <warn> [1466186144.1637] failed to enumerate oFono devices: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
because the code assumes that if the GDBusProxy is created, that
oFono is available. That's not the case with DO_NOT_AUTO_START
because it creates the proxy anyway, and lets the caller listen
for name-owner-changed signals instead. The GDBusProxy also
doesn't need to be cleared, since it will follow name-owner
changes and emit g-name-owner changes when oFono starts/stops.
This also fixes the oFono name-owner-changed watch. It was presumably
using the signal name copied from the ModemManager 'notify::name-owner'
code, but that's a GDBusObjectManagerClient. The oFono code is using
a GDBusProxy for which the signal is 'notify::g-name-owner'.
Finally, the oFono code shouldn't really be piggy-backing on the
ModemManager autolaunch code, it's just cleaner to keep the two
code paths separate and initialize oFono in parallel.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NM_MODEM_UID is used as the modem device name, and the device name
cannot contain path-like characters.
Ofono has a bluez plugin that detects paired DUN/PAN capable
Bluetooth devices, and these devices are created with a multi-component
object path like "/hfp/org/bluez/hci0/dev_00_26_E2_AB_68_66".
The NM ofono plugin cannot use these paths as NM device names.
Instead, strip off any path components and use the last part
of the object path as the NM device name.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
At least, there are assertions that fail and must be fixed.
Still, let's merge the (incomplete) ofono patches early
to have something that can be incrementally improved.
However, for now mark it as experimental and disable it by
default.
|
| | |
| |
| |
| |
| |
| |
| | |
_get_property_path()
If ofono violates these asserts, then the bug must be fixed somewhere
else, not by silently doing something wrong.
|
| | |
| |
| |
| | |
And use gs_free in ofono_check_name_owner()
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This patch adds core wwan support for ofono, as used by Ubuntu Touch.
Signed-off-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00089.html
|
| |/ |
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
DNS properties should not be copied to parent device's configuration
otherwise they will be applied twice, possibly with two different DNS
priorities.
|
| | |
| |
| |
| |
| |
| |
| | |
Be more verbose at TRACE level and log the DNS servers associated to
configurations. This will help to debug issues like [0].
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1348887
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we created a new NMIP[46]Config object to replace the
previous one every time the plugin reported a new IP configuration
through the Ip[46]Config signal, but the old configuration was not
removed from the DNS manager and would become stale.
The interaction with DNS manager is handled by NMPolicy, which only
reacts to changes in connection status, so it's not easy to have the
configuration removed from DNS while keeping the connection state
ACTIVATED.
A cleaner solutions is to avoid creating a new IP configuration object
and reuse the existing one if possible. The side effect is that the
D-Bus path of the object will not change, which seems also positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1348901
|
| |/
|
|
|
|
| |
If the plugin sends a new configuration when the connection is already
activated the state should not go back to PRE_UP since this causes
dispatcher scripts to run again.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This would fix for example:
nmcli e <TAB>
(e interpreted as --escape, would allow autocompletion to work... but
when the command is executed an error is reported)
Moreover, we will now have:
nmcli c <TAB>
autocompletion work correctly, i.e., c is correctly interpreted as
"connection" instead of "--colors"
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The connection list may be required in nmc_secrets_requested() if
secrets are needed.
Fixes: 45fc268890f70fec0fb66c59de388d1798837230
https://bugzilla.gnome.org/show_bug.cgi?id=767987
|
