[PATCH] exported-object: set object path after skeleton creation
When exporting an object, we first set the object path and then create
GDBus interface skeletons. While doing this, a signal can be generated
[1] and then nm_exported_object_signal_hook() can trigger the failed
assertion "interface != NULL" because the object is already exported
(priv->path != NULL) but the interface has not been registered yet.
To fix this, set the object path only after skeletons have been
created.
[1] This happens here every time I disable networking and restart NM:
#0 _g_log_abort (libglib-2.0.so.0)
#1 g_log (libglib-2.0.so.0)
#2 nm_exported_object_signal_hook (NetworkManager)
#3 signal_emit_unlocked_R (libgobject-2.0.so.0)
#4 g_signal_emit_valist (libgobject-2.0.so.0)
#5 g_signal_emit (libgobject-2.0.so.0)
#6 set_state (NetworkManager)
#7 nm_manager_update_state (NetworkManager)
#8 get_property (NetworkManager)
#9 object_get_property (libgobject-2.0.so.0)
#10 on_source_notify (libgobject-2.0.so.0)
#11 g_object_bind_property_full (libgobject-2.0.so.0)
#12 g_object_bind_property (libgobject-2.0.so.0)
#13 nm_exported_object_skeleton_create (NetworkManager)
#14 nm_exported_object_create_skeletons (NetworkManager)
#15 nm_exported_object_export (NetworkManager)
#16 nm_manager_setup (NetworkManager)
#17 main (NetworkManager)
#18 __libc_start_main (libc.so.6)
#19 _start (NetworkManager)
---
src/nm-exported-object.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/nm-exported-object.c b/src/nm-exported-object.c
index ca3187e..8155bab 100644
--- a/src/nm-exported-object.c
+++ b/src/nm-exported-object.c
@@ -533,16 +533,17 @@ nm_exported_object_destroy_skeletons (NMExportedObject
*self)
* Returns: the path @self was exported under
*/
const char *
nm_exported_object_export (NMExportedObject *self)
{
NMExportedObjectPrivate *priv;
const char *class_export_path, *p;
GType type;
+ char *path;
g_return_val_if_fail (NM_IS_EXPORTED_OBJECT (self), NULL);
priv = NM_EXPORTED_OBJECT_GET_PRIVATE (self);
g_return_val_if_fail (!priv->path, priv->path);
g_return_val_if_fail (!priv->bus_mgr, priv->path);
#ifdef _ASSERT_NO_EARLY_EXPORT
@@ -563,29 +564,30 @@ nm_exported_object_export (NMExportedObject *self)
g_return_val_if_fail (strchr (p + 1, '%') == NULL, NULL);
counter = g_hash_table_lookup (prefix_counters,
class_export_path);
if (!counter) {
counter = g_new0 (guint, 1);
g_hash_table_insert (prefix_counters, g_strdup
(class_export_path), counter);
}
- priv->path = g_strdup_printf (class_export_path, (*counter)++);
+ path = g_strdup_printf (class_export_path, (*counter)++);
} else
- priv->path = g_strdup (class_export_path);
-
- _LOGT ("export: \"%s\"", priv->path);
- g_dbus_object_skeleton_set_object_path (G_DBUS_OBJECT_SKELETON (self),
priv->path);
+ path = g_strdup (class_export_path);
type = G_OBJECT_TYPE (self);
while (type != NM_TYPE_EXPORTED_OBJECT) {
nm_exported_object_create_skeletons (self, type);
type = g_type_parent (type);
}
+ priv->path = path;
+ _LOGT ("export: \"%s\"", priv->path);
+ g_dbus_object_skeleton_set_object_path (G_DBUS_OBJECT_SKELETON (self),
priv->path);
+
/* Important: priv->path and priv->interfaces must not change while
* the object is registered. */
nm_bus_manager_register_object (priv->bus_mgr, (GDBusObjectSkeleton *)
self);
return priv->path;
}
--
2.5.0
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] exported-object: set object path after skeleton creation
On Thu, 2016-02-11 at 11:58 +0100, Beniamino Galvani wrote: > When exporting an object, we first set the object path and then > create > GDBus interface skeletons. While doing this, a signal can be > generated > [1] and then nm_exported_object_signal_hook() can trigger the failed > assertion "interface != NULL" because the object is already exported > (priv->path != NULL) but the interface has not been registered yet. > > To fix this, set the object path only after skeletons have been > created. looks good to me. Merged: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=14c16a8b22ed53c40db2c14cb0e76da2c844917c Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can't set two connections up on the same interface
On Wed, 2016-02-10 at 19:56 +0100, Anthony Bourguignon wrote: > Le lundi 11 août 2014 à 10:55 -0500, Dan Williams a écrit : > > On Thu, 2014-08-07 at 23:01 +0200, Anthony Bourguignon wrote: > > > Hi, > > > > > > I'm trying to configure my debian testing router using Network > > > Manager > > > (in replacement of the /etc/network/interfaces file). But I've > > > found an > > > issue. I can't set two connections at the same time on the same > > > network > > > interface. > > > > > > I've configured two connections : a pppoe and a 802-3-ethernet > > > one. > > > They > > > have to work at the same time on the same interface. The ethernet > > > connection is to set a local ip address for me to have access to > > > my > > > adsl > > > modem web interface. The pppoe is to setup my internet > > > connection. > > > > > > Using ifupdown, it works well. Both connections are up without > > > any > > > problem. But Network Manager doesn't allow it. I've bound the 2 > > > connections used by network manager using the 802-3-ethernet.mac- > > > address > > > parameter. > > > > > > But when I set a connection up, the other one is disconnected. I > > > can > > > only have one at a time. > > > > > > Is this normal or is there a way to bypass this behavior ? > > > > At the moment this is expected behavior, and it's a bug in > > NetworkManager that has a long history and hasn't yet been > > fixed. So > > unfortunately NM can't meet your needs at this time. Fixing this > > issue > > has always been in my mind at least, and we've made slow progress > > towards it, but there's still a bunch of stuff to do before it's > > finally > > fixed. > > > > Dan > > Some progress about this issue ? Maybe a bug that I could follow ? Hi Anthony, No progress :( https://bugzilla.gnome.org/show_bug.cgi?id=559134 since you also asked about multiple vpn connections..., that one is fixed on master and will be in the upcoming 1.2 release. Both NM core and the VPN plugin must be updated to support that. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] wifi: allow autoconnect on AP/AdHoc mode connections with manual IP configuration
On Mon, 2016-02-08 at 17:03 -0600, Dan Williams wrote: > The existing checks assumed that all AP/AdHoc connections would use > the > shared IP method. But what we really want to check for here is > whether the > connection is AP/AdHoc. Leave the existing 'shared' check for > backwards > compatibility. > > Also move the check above the timestamp check, since the user > shouldn't need > to manually set a timestamp just to get an AP-mode connection to > autoconnect. > --- > src/devices/wifi/nm-device-wifi.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) > Patch lgtm, but it doesn't apply anywhere. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager starts infinite number of VPN daemons
On Tue, 2016-02-02 at 23:09 +0100, Adrian Freihofer wrote:
> Hi Dan
>
> This is my VPN connection configuration:
> settings = {u'connection': {u'type': u'vpn',
> u'autoconnect': True,
'autoconnect' of VPN connections has no effect (but doesn't hurt
either).
> u'zone': 'trusted'},
> u'vpn': {u'service-type':
> u'org.freedesktop.NetworkManager.openvpn',
> u'data': {u'cert-pass-flags': u'4',
> u'connection-type': u'tls',
> u'remote-cert-tls': u'server',
> ... + credentials and other details
> ...
> }
> },
> u'ipv4': {u'method': u'auto',
> u'may-fail': False,
> u'never-default': True
> },
> u'ipv6': {u'method': u'ignore'},
> }
>
> Finally the connection is activated by:
> NetworkManager.ActivateConnection(connection, '/', '/')
>
> My assumptions (which were true for NM 0.9...):
> - The first '/' means "auto select the device"
> - As soon as NM is connected it will try to setup the VPN connection
> because of the autoconnect=true flag in the VPN configuration.
when you activate a VPN connection, it does not automatically connect
another device.
It tries to activate only the VPN connection. A
prerequisite for that is that another device is connected.
> With NM 1.0.10: For WLAN and for Ethernet devices it works as
> expected (by me), but for GSM devices the VPN connection is not
> automatically
> established e.g. after rebooting the system.
> What do you exactly mean with set as a "secondary" of wwan? How do I
> need to change my configuration?
As said, autoconnect doesn't work for VPNs. But you can set the vpn
connection as "secondary" for another connection.
E.g. modify your Wi-Fi connection to activate your VPN connection when
the Wi-Fi connection activates.
In nm-connection-editor this is called:
"Automatically connect to VPN when using this connection".
> Personally I consider this as a bug:
> - If the autoconnect flag is available for VPN connections, NM should
> not ignore it.
Yeah, it's a bug/missing feature.
> - With NM 0.9 it just worked for all types of devices.
I don't think that changed.
> - Different behavior for different devices is inconsistent.
Yes, that would be bad, but I am not sure there is a difference here.
> What do you think; is it a bug or the expected bahavior?
> Are you interested in log files (e.g. one capturing booting with
> Ethernet enabled and one capturing booting with GSM enabled)?
Before activating the VPN connection, you should ensure that you
activate another connection (ethernet, Wi-Fi, GSM) to give you internet
connectivity. That other connection can be configured to "autoconnect"
as you like.
Good luck,
Thomas
>
> Thank you and regards,
> Adrian
>
>
> On Mon, 2016-02-01 at 13:34 -0600, Dan Williams wrote:
> > On Fri, 2016-01-29 at 23:44 +0100, Adrian Freihofer wrote:
> > > Hi Thomas
> > >
> > > Thank you for taking care about this issue.
> > > With my current setup I'm able to reproduce this. Unfortunately I
> > > cannot use NetworkManager 1.2. I'm working on a cross compiled
> > > Embedded System (based on Yocto). I guess NM 1.2 has been ported
> > > to
> > > GObject, which cannot be cross compiled by design.
> > > Yocto next will provide a solution based on Qemu. But my project
> > > is
> > > not in a phase where I can upgrade the OS to current unstable
> > > branch
> > > right now. Are you able to reproduce and test this?
> > > I found a workaround to relax the situation for my use case: If
> > > the
> > > interfaces are enabled exclusively NM works more stable. Given
> > > this
> > > patch cannot be back ported this is OK for me now.
> > >
> > >
> > > There is another finding related to the the same use case and
> > > setup.
> > > I have a VPN connection configured with autoconnect=true.
> > > As a physical connection there are three different types
> > > available:
> > > Ethernet, WLAN and Mobile. Due to the problem you hopefully
> > > solved
> > > now,
> > > they are enabled only exclusively now. With Ethernet and WLAN NM
> > > works
> > > perfect: After the physical connection has established, NM
> > > immediately
> > > setup the VPN connection. With Mobile connection VPN is not
> > > automatically
> > > established by NM. Only a manual trigger gets the VPN connection
> > > establishing.
> > > With latest 0.9 version of NM this worked great. With 1.0.10 it
> > > does
> > > not.
> > > Also rebooting the system behaves similar. The Mobile connection
> > > is
> > > established but not the VPN.
> >
> > Debug logs from this last case (WWAN+VPN) would be nice to have
> > here.
> >
> > And just to be sure, you have the VPN connection set as a
> > "secondary"
> > on the WWAN
Re: [PATCH] wifi: allow autoconnect on AP/AdHoc mode connections with manual IP configuration
On Thu, 2016-02-11 at 13:21 +0100, Thomas Haller wrote: > On Mon, 2016-02-08 at 17:03 -0600, Dan Williams wrote: > > The existing checks assumed that all AP/AdHoc connections would use > > the > > shared IP method. But what we really want to check for here is > > whether the > > connection is AP/AdHoc. Leave the existing 'shared' check for > > backwards > > compatibility. > > > > Also move the check above the timestamp check, since the user > > shouldn't need > > to manually set a timestamp just to get an AP-mode connection to > > autoconnect. > > --- > > src/devices/wifi/nm-device-wifi.c | 19 +-- > > 1 file changed, 13 insertions(+), 6 deletions(-) > > > > > Patch lgtm, but it doesn't apply anywhere. Sorry, patch was against 1.0. I've fixed it up for master and pushed to 1.0 and master. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
