Re: Build Error on Raspberry Pi
Hey Dan,
Thanks for the quick response. Here are the compile errors adding those
lines in nm-ppp-manager.c:
In file included from ppp-manager/nm-ppp-manager.c:42:0:
/usr/include/linux/if_ppp.h:103:16: error: field 'b' has incomplete type
struct ifreq b;
^
/usr/include/linux/if_ppp.h:108:21: error: field 'b' has incomplete type
struct ifreq b;
^
ppp-manager/nm-ppp-manager.c:52:1: error: expected identifier or '('
before numeric constant
linux if has been included!
^
In file included from ../libnm-core/nm-core-internal.h:39:0,
from ppp-manager/nm-ppp-manager.c:54:
../libnm-core/nm-setting-8021x.h:51:3: error: data definition has no
type or storage class [-Werror]
} NMSetting8021xCKFormat;
^
../libnm-core/nm-setting-8021x.h:51:3: error: type defaults to 'int' in
declaration of 'NMSetting8021xCKFormat' [-Werror=implicit-int]
../libnm-core/nm-setting-8021x.h:173:71: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:195:71: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:214:71: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:236:75: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:254:75: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:259:1: error: unknown type name
'NMSetting8021xCKFormat'
NMSetting8021xCKFormat nm_setting_802_1x_get_private_key_format
(NMSetting8021x *setting);
^
../libnm-core/nm-setting-8021x.h:268:75: error: expected declaration
specifiers or '...' before 'NMSetting8021xCKFormat'
NMSetting8021xCKFormat *out_format,
^
../libnm-core/nm-setting-8021x.h:273:1: error: unknown type name
'NMSetting8021xCKFormat'
NMSetting8021xCKFormat nm_setting_802_1x_get_phase2_private_key_format
(NMSetting8021x *setting);
^
cc1: all warnings being treated as errors
Makefile:1499: recipe for target 'nm-ppp-manager.lo' failed
make[4]: *** [nm-ppp-manager.lo] Error 1
make[4]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'
Makefile:2001: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'
Makefile:1051: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/pi/NetworkManager-1.0.0/src'
Makefile:608: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/pi/NetworkManager-1.0.0'
Makefile:502: recipe for target 'all' failed
make: *** [all] Error 2
Here are my compiler flags:
*CFLAGS =* -Wall -std=gnu89 -Wshadow -Wmissing-declarations
-Wmissing-prototypes -Wdeclaration-after-statement -Wformat-security
-Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -Wstrict-prototypes
-fno-strict-aliasing -Wno-unused-but-set-variable -Wundef
-Wimplicit-function-declaration -Wpointer-arith -Winit-self
-Wmissing-include-dirs -Werror -g -O2
Thank you,
Jordan Messina
On Tue, Mar 24, 2015 at 5:05 PM, Dan Williams d...@redhat.com wrote:
On Tue, 2015-03-24 at 13:53 -0400, Jordan Messina wrote:
I'm trying to build Network Manager 1.0 from source on a Raspberry Pi
running RASPBIAN Debian Wheezy. I'm using gcc4.8. Getting the following
error:
Interesting; linux/if.h should get pulled in from the #include
nm-platform.h in nm-ppp-manager.c. Can you do something like:
#include nm-platform.h
+#ifdef _LINUX_IF_H
+linux if has been included!
+#endif
#include nm-core-internal.h
in nm-ppp-manager.c and see if the compiler errors on that? If so we
know linux/if.h has been found by the preprocessor.
Also, what compiler flags are being used? This should tell you:
grep ^CFLAGS = src/ppp-manager/Makefile
Dan
In file included from
ppp-manager/nm-ppp-manager.c:42:0:/usr/include/linux/if_ppp.h:103:16:
error: field 'b' has incomplete type
struct ifreq b;
^/usr/include/linux/if_ppp.h:108:21: error: field 'b'
has incomplete type
struct ifreq b;
^Makefile:1499: recipe for target
'nm-ppp-manager.lo' failed
make[4]: *** [nm-ppp-manager.lo] Error 1
make[4]:
Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired
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 d...@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 d...@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
Re: NMClient.IP4Config get_addresses() not always populated when signal 'notify::ip4-config' is fired
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 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 d...@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 d...@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 d...@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
