GNOME.org
 

Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired

On Wed, 2015-03-25 at 22:20 +0100, Sylvain Garaud wrote:

Hello Dan,

Trying your script with both connections on, then I turn off and on my
ethernet connection
I get the following ouput.

Connecting to wlp5s0
Connecting to enp4s0
Connecting to lo
notify: <GParamObject 'ip4-config'> ::::: state 100
    192.168.0.4/24  192.168.0.1
notify: <GParamObject 'ip4-config'> ::::: state 100
    192.168.0.10/24  192.168.0.1
notify: <GParamObject 'ip4-config'> ::::: state 10
    127.0.0.1/8  0.0.0.0
notify: <GParamObject 'ip4-config'> ::::: state 30
notify: <GParamObject 'ip4-config'> ::::: state 100


I think I see what the issue here is.  From your dbus-monitor traces,
the interface's configuration has IPv6 enabled.  IPv6 appears to
complete first and that causes the device to enter the ACTIVATED state
because it has IPv6 connectivity of some kind.  IPv4 takes a while
longer to complete and so the IP4Config object is updated after the
state change to ACTIVATED.

Also, the IP4Config object can live for long periods of time as it can
contain external information that is set outside NM.  So just getting a
signal saying 'ip4-config changed' doesn't mean that anything *in* the
Ip4Config has changed, it simply means that the Device object created a
new Ip4Config object.  The IP4Config object can change properties later
too, in response to a DHCP renewal, so it's best to monitor the
IP4Config object directly so you know about all addressing changes.

What I think you want to do is the following:

1) whenever you get the notify::ip4-config signal, get the new
NMIP4Config object and listen for address changes with
"notify::addresses".  Disconnect the listen for the old IP4Config.
There will only ever be one at a time.

2) when the signal handler for notify::addresses is called, then check
the device state and if it is >= IP_CHECK and <= DISCONNECTING then you
update your UI or whatever you need to do

I've attached an updated notify-ips.py script that shows what should be
done here.  Let me know if you have any questions!

Dan


I do not see the ethernet ip in state 100.
If I do the same test with my wifi connection, I get

Connecting to wlp5s0
Connecting to enp4s0
Connecting to lo
notify: <GParamObject 'ip4-config'> ::::: state 100
    192.168.0.10/24  192.168.0.1
notify: <GParamObject 'ip4-config'> ::::: state 100
    192.168.0.4/24  192.168.0.1
notify: <GParamObject 'ip4-config'> ::::: state 10
    127.0.0.1/8  0.0.0.0
notify: <GParamObject 'ip4-config'> ::::: state 20
notify: <GParamObject 'ip4-config'> ::::: state 80
    192.168.0.4/24  192.168.0.1


Regards,

Sylvain

On Wed, Mar 25, 2015 at 3:57 PM, Dan Williams <dcbw redhat com> wrote:


On Mon, 2015-03-23 at 22:39 +0100, Sylvain Garaud wrote:

Hello,

You are perfectly right. I used finally the ip4config and not the dhcp4
config to get the ip. Looking at the dbus-monitor logs I thought I could
save the ip decoding step by using the dhcp4 config. But it is not enough
generic.


Just to rule out some other stuff, can you try the attached Python
program?  Just run it (python notify-ips.py) and then reproduce the
issue with ethernet.  Do you get output like:

notify: <GParamObject 'ip4-config'> ::::: state 80
192.168.1.197/24  192.168.1.1

or do you get something else?

Thanks!
Dan


Here is the log where I simply go from wired ethernet off to on. I think

I

get an ip4config signal from the line 204 in the log but it does not
include the addresses. The "real" one is at line 403. Not so sure what is
the expected behavior. I have the following piece of code at line 166

which

seems to work ok for that case.


https://github.com/sgaraud/gnome-extension-show-ip/blob/master/extension.js#L166

at line 173, this is for the case when I sometimes get double

notifications

if I put up the ethernet com then down just before it get the dhcp4

config

and up again. At that time it seems I get some old signals.

Regards,

Sylvain



On Mon, Mar 23, 2015 at 5:58 PM, Dan Williams <dcbw redhat com> wrote:


On Fri, 2015-03-20 at 01:31 +0100, Sylvain Garaud wrote:

Hello Dan,

Thank you for the answer.
I am using NM lib version 0.9.10.0
I use the dbus-monitor command you provided.
It helped me greatly to understand my problem.

In most cases the ip info I am interested in was defined when the

IP4Config

propertiesChanges signal was received. But it was not always the case
depending of the network interface type and disconnection time. My

routine

using the  gi.NMClient was also missing to capture some signals that

I

saw

with the dbus-monitor as sometimes they were arriving in a burst.

Eventually I implemented the following solution that seems to be

working

properly.

1. I register a callback on the device "state-changed" signal
2. Within the callback, I try immediately to get the ip address

inside

the

dhcp4 config.
3. If I get it I am done, otherwise it is undefined and I simply

register a

callback on the dhcp4 options signal that hopefully will arrive

later.


I tested it with several configuration and it seems to work

correctly.


Getting the IP address through the DHCP4 config won't give you user
overrides, secondary IP addresses, or static IP configurations though.
This still sounds like a bug in NM or libnm-glib, and if you still have
the logs from dbus-monitor I'd like to take a look.

Thanks!
Dan


Thank you so much,

Sylvain


On Wed, Mar 18, 2015 at 3:44 PM, Dan Williams <dcbw redhat com>

wrote:



On Sun, 2015-03-15 at 12:46 +0100, Sylvain Garaud wrote:

Hello,

I am writing a small javascript for gnome to grab the ip

addresses

of my

network interfaces using imports.gi.NMClient;
Basically I get the devices and connect each device to the
notify::ip4-config signal to be able to update the ip address

value

when

it

changes


Which version of NM are you using?

this.client = NMC.Client.new();

this.devices = this.client.get_devices();
for each (let device in this.devices) {


 device.connect('notify::ip4-config',Lang.bind(this,this._update));

}

It works fine for the wifi connection but there is a problem

with the

ethernet connection.
After turning my ethernet connection up,  the signal

'notify::ip4-config'

is fired, the device state is ACTIVATED, so I try to get the ip4

config.

with ipcfg = device.get_ip4_config();
I get a not null ipcfg object, unfortunately

ipcfg.get_addresses()

is not

defined yet.


So that we can narrow the issue down, could you run:

dbus-monitor --system
"type='signal',sender='org.freedesktop.NetworkManager'"

and reproduce the problem?  This will let us know the sequence of

D-BUs

events that come directly from NetworkManager, so that we can see

the

raw data that libnm/libnm-glib is getting.

Dan




I see in my journalctl log few seconds later, some dhcp network

manager

message.

 _update: function(device) {
      let ipcfg = device.get_ip4_config();
      if (ipcfg != null) {
         for each(let addr in ipcfg.get_addresses()){
            let num = addr.get_address();
         }
      }
   },

How to be sure ipcfg.get_addresses() will return something ?
Could someone tell me which signal to use for being sure the ip

address

is

set when calling ipcfg.get_addresses()? I tried using the
'notify::dhcp4-config' signal instead 'notify::ip4-config'

without

much

success.

Thank you very much for your help,

Sylvain
_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Attachment: notify-ips.py
Description: Text Data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]