NetworkManager process dies sometimes
This is for embedded system, kernel 3.0.35-cm-fx6-4, fs is using ubuntu 12.02。NetworkManager version is 0.9.4. Since this is embedded system, there's no GUI, you can just view message outputs from console.(BUT we do have 2 login sessions, 1 is for GUI, don't ask me why, someone else did it) We use networkmanager to manager the 2 ethernet ports. Most of the time it's fine.0Once a while no network connection, and turned out to be networkmanager process has died.Pls note this could happen during weekends, no one is touching the board, our application should has nothing to with it. Also Not sure if related, but someone's board displays this, ** (process:3): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Error: nmcli (0.9.4.0) and NetworkManager (unknown) versions don't match. Force execution using --nocheck, but the results are unpredictable. The funny thing is, our NetworkManager is 0.9.4 from "--version".Where should i get started on this pls ? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager creating IPv6 routes on the fly?
- Original Message - > From: "Dan Williams" > To: "Bjørn Mork" > Cc: "Pavel Simerda" , networkmanager-list@gnome.org > Sent: Thursday, February 13, 2014 7:05:59 PM > Subject: Re: NetworkManager creating IPv6 routes on the fly? > > On Thu, 2014-02-13 at 11:05 +0100, Bjørn Mork wrote: > > Pavel Simerda writes: > > > > > Those are device routes created to mimic the kernel-installed routes > > > but with a proper metric to prioritize the selected interface. It is a > > > hack in 0.9.8 (and prior) to get over kernel's crazy autoconfiguration > > > feature. > > > > Trying to work around kernel features you don't like is guaranteed to > > cause you and your users a lot of pain. It certainly was causing a lot of pain and that's why I decided to get rid of kernel autoconf entirely some time ago and also why other developers agreed with me. They have recently updated this decision with a bit of more cooperation regarding temporary addresses and added kernel features for that. > > This isn't supposed to be a war between kernel and userspace. NetworkManager is often the main driver for kernel network configuration features. You are welcome to install and test a git snapshot of NetworkManager and/or participate in the development. > We've actually been doing that, for example with the IPv6 tempaddr > changes that recently went upstream. We intend to keep doing that going > forward too. It's just that 0.9.8 was the point where we started doing > that. > > That said, we haven't yet figured out how to solve the metric thing that > Pavel is talking about here. Yep. At least not some specific details like changing the metric without disturbing network communication, and also the specific way of choosing the metric. In my opinion, the kernel is not yet mature for this kind of operation. Pavel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[review] dcbw/wwan-fu: various fixes for mobile broadband (bgo #724314)
Branch review request. https://bugzilla.gnome.org/show_bug.cgi?id=724314 A couple fixes for mobile broadband here, and one cleanup. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] libnm-glib: suppress warnings unless LIBNM_GLIB_DEBUG is set
On Thu, 2014-02-13 at 11:17 -0500, Dan Winship wrote:
> sure. The "unknown object type" one always annoys me...
Pushed.
Dan
>
> On 02/06/2014 05:51 AM, Dan Williams wrote:
> > Most of these warnings are things libnm-glib can't do anything
> > about, and they are pretty annoying when running nmcli or nmtui,
> > and libraries usually shouldn't print random warnings anyway.
> > Downgrade them to debug messages that can be enabled if we need
> > to see them.
> > ---
> > libnm-glib/nm-object.c | 77
> > +++---
> > 1 file changed, 36 insertions(+), 41 deletions(-)
> >
> > diff --git a/libnm-glib/nm-object.c b/libnm-glib/nm-object.c
> > index 497f6c3..2fbc4f1 100644
> > --- a/libnm-glib/nm-object.c
> > +++ b/libnm-glib/nm-object.c
> > @@ -150,15 +150,15 @@ constructor (GType type,
> > object = G_OBJECT_CLASS (nm_object_parent_class)->constructor (type,
> >
> > n_construct_params,
> >
> > construct_params);
> >
> > priv = NM_OBJECT_GET_PRIVATE (object);
> >
> > if (priv->connection == NULL || priv->path == NULL) {
> > - g_warning ("%s: bus connection and path required.", __func__);
> > + g_warn_if_reached ();
> > g_object_unref (object);
> > return NULL;
> > }
> >
> > _nm_object_cache_add (NM_OBJECT (object));
> >
> > return object;
> > @@ -566,27 +566,26 @@ _nm_object_create (GType type, DBusGConnection
> > *connection, const char *path)
> > GError *error = NULL;
> >
> > type_func = g_hash_table_lookup (type_funcs, GSIZE_TO_POINTER (type));
> > if (type_func)
> > type = type_func (connection, path);
> >
> > if (type == G_TYPE_INVALID) {
> > - g_warning ("Could not create object for %s: unknown object
> > type", path);
> > + dbgmsg ("Could not create object for %s: unknown object type",
> > path);
> > return NULL;
> > }
> >
> > object = g_object_new (type,
> >NM_OBJECT_DBUS_CONNECTION, connection,
> >NM_OBJECT_DBUS_PATH, path,
> >NULL);
> > if (!g_initable_init (G_INITABLE (object), NULL, &error)) {
> > - g_object_unref (object);
> > - object = NULL;
> > - g_warning ("Could not create object for %s: %s", path,
> > error->message);
> > + dbgmsg ("Could not create object for %s: %s", path,
> > error->message);
> > g_error_free (error);
> > + g_clear_object (&object);
> > }
> >
> > return object;
> > }
> >
> > typedef void (*NMObjectCreateCallbackFunc) (GObject *, const char *,
> > gpointer);
> > typedef struct {
> > @@ -620,21 +619,19 @@ static void
> > async_inited (GObject *source, GAsyncResult *result, gpointer user_data)
> > {
> > NMObjectTypeAsyncData *async_data = user_data;
> > GObject *object = G_OBJECT (source);
> > GError *error = NULL;
> >
> > if (!g_async_initable_init_finish (G_ASYNC_INITABLE (object), result,
> > &error)) {
> > - if (!g_error_matches (error, DBUS_GERROR,
> > DBUS_GERROR_UNKNOWN_METHOD)) {
> > - g_warning ("Could not create object for %s: %s",
> > - nm_object_or_connection_get_path (object),
> > error->message);
> > - }
> > + dbgmsg ("Could not create object for %s: %s",
> > + nm_object_or_connection_get_path (object),
> > + error->message);
> > g_error_free (error);
> > - g_object_unref (object);
> > - object = NULL;
> > + g_clear_object (&object);
> > }
> >
> > create_async_complete (object, async_data);
> > }
> >
> > static void
> > async_got_type (GType type, gpointer user_data)
> > @@ -1024,18 +1021,18 @@ handle_property_changed (NMObject *self, const char
> > *dbus_name, GValue *value, g
> > if (!found) {
> > dbgmsg ("Property '%s' unhandled.", prop_name);
> > goto out;
> > }
> >
> > pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (G_OBJECT
> > (self)), prop_name);
> > if (!pspec) {
> > - g_warning ("%s: property '%s' changed but wasn't defined by
> > object type %s.",
> > - __func__,
> > - prop_name,
> > - G_OBJECT_TYPE_NAME (self));
> > + dbgmsg ("%s: property '%s' changed but wasn't defined by object
> > type %s.",
> > + __func__,
> > + prop_name,
> > + G_OBJECT_TYPE_NAME (self));
> > goto out;
> > }
> >
> > if (G_UNLIKELY (debug)) {
> > char *s;
> > s = g_strdup_value_contents (value);
> > dbgmsg ("PC: (%p) %s::%s => '%s' (%s%s%s)",
> > @@ -105
Re: NetworkManager creating IPv6 routes on the fly?
On Thu, 2014-02-13 at 11:05 +0100, Bjørn Mork wrote: > Pavel Simerda writes: > > > Those are device routes created to mimic the kernel-installed routes > > but with a proper metric to prioritize the selected interface. It is a > > hack in 0.9.8 (and prior) to get over kernel's crazy autoconfiguration > > feature. > > Trying to work around kernel features you don't like is guaranteed to > cause you and your users a lot of pain. This isn't supposed to be a war > between kernel and userspace. We've actually been doing that, for example with the IPv6 tempaddr changes that recently went upstream. We intend to keep doing that going forward too. It's just that 0.9.8 was the point where we started doing that. That said, we haven't yet figured out how to solve the metric thing that Pavel is talking about here. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] libnm-glib: suppress warnings unless LIBNM_GLIB_DEBUG is set
sure. The "unknown object type" one always annoys me...
On 02/06/2014 05:51 AM, Dan Williams wrote:
> Most of these warnings are things libnm-glib can't do anything
> about, and they are pretty annoying when running nmcli or nmtui,
> and libraries usually shouldn't print random warnings anyway.
> Downgrade them to debug messages that can be enabled if we need
> to see them.
> ---
> libnm-glib/nm-object.c | 77
> +++---
> 1 file changed, 36 insertions(+), 41 deletions(-)
>
> diff --git a/libnm-glib/nm-object.c b/libnm-glib/nm-object.c
> index 497f6c3..2fbc4f1 100644
> --- a/libnm-glib/nm-object.c
> +++ b/libnm-glib/nm-object.c
> @@ -150,15 +150,15 @@ constructor (GType type,
> object = G_OBJECT_CLASS (nm_object_parent_class)->constructor (type,
>
> n_construct_params,
>
> construct_params);
>
> priv = NM_OBJECT_GET_PRIVATE (object);
>
> if (priv->connection == NULL || priv->path == NULL) {
> - g_warning ("%s: bus connection and path required.", __func__);
> + g_warn_if_reached ();
> g_object_unref (object);
> return NULL;
> }
>
> _nm_object_cache_add (NM_OBJECT (object));
>
> return object;
> @@ -566,27 +566,26 @@ _nm_object_create (GType type, DBusGConnection
> *connection, const char *path)
> GError *error = NULL;
>
> type_func = g_hash_table_lookup (type_funcs, GSIZE_TO_POINTER (type));
> if (type_func)
> type = type_func (connection, path);
>
> if (type == G_TYPE_INVALID) {
> - g_warning ("Could not create object for %s: unknown object
> type", path);
> + dbgmsg ("Could not create object for %s: unknown object type",
> path);
> return NULL;
> }
>
> object = g_object_new (type,
> NM_OBJECT_DBUS_CONNECTION, connection,
> NM_OBJECT_DBUS_PATH, path,
> NULL);
> if (!g_initable_init (G_INITABLE (object), NULL, &error)) {
> - g_object_unref (object);
> - object = NULL;
> - g_warning ("Could not create object for %s: %s", path,
> error->message);
> + dbgmsg ("Could not create object for %s: %s", path,
> error->message);
> g_error_free (error);
> + g_clear_object (&object);
> }
>
> return object;
> }
>
> typedef void (*NMObjectCreateCallbackFunc) (GObject *, const char *,
> gpointer);
> typedef struct {
> @@ -620,21 +619,19 @@ static void
> async_inited (GObject *source, GAsyncResult *result, gpointer user_data)
> {
> NMObjectTypeAsyncData *async_data = user_data;
> GObject *object = G_OBJECT (source);
> GError *error = NULL;
>
> if (!g_async_initable_init_finish (G_ASYNC_INITABLE (object), result,
> &error)) {
> - if (!g_error_matches (error, DBUS_GERROR,
> DBUS_GERROR_UNKNOWN_METHOD)) {
> - g_warning ("Could not create object for %s: %s",
> -nm_object_or_connection_get_path (object),
> error->message);
> - }
> + dbgmsg ("Could not create object for %s: %s",
> + nm_object_or_connection_get_path (object),
> + error->message);
> g_error_free (error);
> - g_object_unref (object);
> - object = NULL;
> + g_clear_object (&object);
> }
>
> create_async_complete (object, async_data);
> }
>
> static void
> async_got_type (GType type, gpointer user_data)
> @@ -1024,18 +1021,18 @@ handle_property_changed (NMObject *self, const char
> *dbus_name, GValue *value, g
> if (!found) {
> dbgmsg ("Property '%s' unhandled.", prop_name);
> goto out;
> }
>
> pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (G_OBJECT
> (self)), prop_name);
> if (!pspec) {
> - g_warning ("%s: property '%s' changed but wasn't defined by
> object type %s.",
> -__func__,
> -prop_name,
> -G_OBJECT_TYPE_NAME (self));
> + dbgmsg ("%s: property '%s' changed but wasn't defined by object
> type %s.",
> + __func__,
> + prop_name,
> + G_OBJECT_TYPE_NAME (self));
> goto out;
> }
>
> if (G_UNLIKELY (debug)) {
> char *s;
> s = g_strdup_value_contents (value);
> dbgmsg ("PC: (%p) %s::%s => '%s' (%s%s%s)",
> @@ -1057,18 +1054,18 @@ handle_property_changed (NMObject *self, const char
> *dbus_name, GValue *value, g
> g_warn_if_reached ();
> goto out;
>
Re: NetworkManager creating IPv6 routes on the fly?
Pavel Simerda writes: > Those are device routes created to mimic the kernel-installed routes > but with a proper metric to prioritize the selected interface. It is a > hack in 0.9.8 (and prior) to get over kernel's crazy autoconfiguration > feature. Trying to work around kernel features you don't like is guaranteed to cause you and your users a lot of pain. This isn't supposed to be a war between kernel and userspace. Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager creating IPv6 routes on the fly?
- Original Message - > From: "Dan Irwin" > To: networkmanager-list@gnome.org > Sent: Tuesday, February 11, 2014 7:45:00 AM > Subject: NetworkManager creating IPv6 routes on the fly? > > Following up my previous post, I am noticing something creating IPv6 routes > on my local routing table: > > 2404:6800:4004:805::1007 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1003 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1005 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1007 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1009 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::100a via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::100b via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::100c via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::100f via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1011 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::1015 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4006:806::101d via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4008:c03::54 via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2404:6800:4008:c03::5f via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > 2a00:1450:4001:807::100f via fe80::d267:e5ff:feb5:235b dev em1 proto static > metric 1 > > Seeing as this seems "weird", I'm assuming these are also created by > NetworkManager. > > My only question is why? These routes surely are not needed for anything if > we have a working default route. Those are device routes created to mimic the kernel-installed routes but with a proper metric to prioritize the selected interface. It is a hack in 0.9.8 (and prior) to get over kernel's crazy autoconfiguration feature. Pavel > > Cheers, > > Dan > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 breakage caused by active IPv6 on an inactive interface?
- Original Message - > From: "Dan Irwin" > To: networkmanager-list@gnome.org > Sent: Tuesday, February 11, 2014 7:42:48 AM > Subject: IPv6 breakage caused by active IPv6 on an inactive interface? > > Hello, > > I suspect NetworkManager has a small problem regarding IPv6 and > disabled/inactive interfaces. > > I have noticed some IPv6 breakage in Fedora 20, and I posted about that to > the fedora list. > > Today when IPv6 stopped working, I noticed I had two default routes: > > default via fe80::d267:e5ff:feb5:235b dev wlp2s0 proto static metric 1024 > default via fe80::d267:e5ff:feb5:235b dev em1 proto ra metric 1024 expires > 593sec > > However, I have em1 disabled in NetworkManager. > > I can only imagine that my ipv6 default route will bounce around depending on > ra timeout values, which explains some of the behaviour I have been seeing. > > Is anyone else seeing this? Specifically a disabled wired interface which > seems to be erroneously up and accepting ra advertisments. Yep, kernel is always trying to do its own stuff with IPv6, but that will be disabled in 0.9.10 and instead NetworkManager will handle it properly and only ask kernel to work with the interfaces when appropriate. I don't remember the exact way 0.9.8 handled 'disconnected' devices but it would be certainly possible to fix that using accept_ra=0 (not that I'm doing anything with 0.9.8 branch, it's just a remark). Cheers, Pavel > Cheers, > > Dan > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
