OCaml Forge

Detail: [#926] Signals on interfaces for changed properties

Support: Browse | Download .csv | Monitor

[#926] Signals on interfaces for changed properties

Date:
2011-03-08 18:01
Priority:
3
State:
Open
Submitted by:
Viktor S. Wold Eide (viktor)
Assigned to:
Nobody (None)
Component:
None
Severity:
None
Version:
None
Hardware:
None
Operating System:
None
Product:
None
URL:
 
Summary:
Signals on interfaces for changed properties

Detailed description
Hi,

I would like to receive signals (along with property changes) whenever
DHCP4Config happens, via OBus. These signals are sent on the dbus
system bus as can be verified with the dbus-monitor command when
activating a network interface, as seen in the example below:

$ dbus-monitor --system --monitor type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged
<cut>
signal sender=org.freedesktop.DBus -> dest=:1.1098 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.1098"
signal sender=:1.5 -> dest=(null destination) serial=92241 path=/org/freedesktop/NetworkManager/DHCP4Config/162; interface=org.freedesktop.NetworkManager.DHCP4Config; member=PropertiesChanged
array [
dict entry(
string "Options"
variant array [
dict entry(
string "domain_name_servers"
variant
<cut>

I might be misunderstanding something, but it appears that a proxy is
needed in order to create the signal descriptor for these signals, via:

OBus_signal.make Nm_interfaces.Org_freedesktop_NetworkManager_DHCP4Config.s_PropertiesChanged proxy

The proxy has an associated path which will later be part of the match
rule when connecting. Hence, the path will be used in
org.freedesktop.DBus.AddMatch on the "wire".

When a path "key" is present in AddMatch , no signals are sent out on
the dbus. As an example, no signals are received if the path "key" is present when
using dbus-monitor, ala:

dbus-monitor --system --monitor type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged',path='/org/freedesktop/NetworkManager/DCHP4Config'

I also tried to remove the path from OBus_match.export in the connect
function in oBusSignal.ml, and then the signals are sent over the
socket to OBus/application.


Best regards
Viktor S. Wold Eide

Followup

Message
Date: 2011-03-18 17:11
Sender: Viktor S. Wold Eide

I was using a patched version of ocaml, more specifically 3.12.0+dev27+camlspotter. With a "clean" 3.12, the latest dev versions of both lwt and obus compile without a problem.
Date: 2011-03-16 23:50
Sender: Jérémie Dimino

Sorry, i meant commenting part of lwt_unix.ml to see exactly from where come the error in this file. Camlp4 sometimes report errors at the wrong location.
Date: 2011-03-16 22:03
Sender: Viktor S. Wold Eide

It does not seem to help to "disable" sched_getcpu and affinity getting/setting.

I: Running command 'ocaml discover.ml -ocamlc /hom/viktore/godis/godi-3.12-spot/bin/ocamlc.opt -ext-obj .o -exec-name a.out'
testing for libev: ............................. available
testing for pthread: ........................... available
testing for eventfd: ........................... available
testing for fd passing: ........................ available
testing for sched_getcpu: ...................... unavailable
testing for affinity getting/setting: .......... unavailable
testing for credentials getting: ............... available

Still geting an error. Maybe newer version of some other package is required.

ocaml setup.ml -build
I: Running command '/hom/viktore/godis/godi-3.12-spot/bin/ocamlbuild src/core/lwt.cma src/core/lwt.cmxa src/core/lwt.a src/unix/liblwt-unix.a src/unix/dlllwt-unix.so src/unix/lwt-unix.cma src/unix/lwt-unix.cmxa src/unix/lwt-unix.a tests/test.cma tests/test.cmxa tests/test.a tests/unix/main.native -tag debug'
Finished, 1 target (0 cached) in 00:00:00.
+ ocamlfind ocamldep -package unix -package camlp4 -package bigarray -syntax camlp4o -ppopt syntax/pa_lwt_options.cmo -ppopt syntax/pa_lwt.cmo -ppopt syntax/pa_lwt_log.cmo -ppopt syntax/pa_optcomp.cmo -ppopt -let -ppopt 'windows=false' -modules src/unix/lwt_unix.ml > src/unix/lwt_unix.ml.depends
File "src/unix/lwt_unix.ml", line 2085, characters 4-17:
Failure: "unbound value HAVE_AFFINITY"
Preprocessing error on file src/unix/lwt_unix.ml
Command exited with code 2.
Compilation unsuccessful after building 110 targets (0 cached) in 00:00:12.
E: Command '/hom/viktore/godis/godi-3.12-spot/bin/ocamlbuild src/core/lwt.cma src/core/lwt.cmxa src/core/lwt.a src/unix/liblwt-unix.a src/unix/dlllwt-unix.so src/unix/lwt-unix.cma src/unix/lwt-unix.cmxa src/unix/lwt-unix.a tests/test.cma tests/test.cmxa tests/test.a tests/unix/main.native -tag debug' terminated with error code 10
Date: 2011-03-16 10:50
Sender: Jérémie Dimino

I cannot reproduce the error, could you try to comment parts of the code to find from where the error come from ?
Date: 2011-03-16 09:21
Sender: Viktor S. Wold Eide

I have some problem compiling the latest dev version of lwt.

ocaml setup.ml -build
I: Running command '/hom/viktore/godis/godi-3.12-spot/bin/ocamlbuild src/core/lwt.cma src/core/lwt.cmxa src/core/lwt.a src/unix/liblwt-unix.a src/unix/dlllwt-unix.so src/unix/lwt-unix.cma src/unix/lwt-unix.cmxa src/unix/lwt-unix.a tests/test.cma tests/test.cmxa tests/test.a tests/unix/main.native -tag debug'
Finished, 1 target (0 cached) in 00:00:00.
+ ocamlfind ocamldep -package unix -package camlp4 -package bigarray -syntax camlp4o -ppopt syntax/pa_lwt_options.cmo -ppopt syntax/pa_lwt.cmo -ppopt syntax/pa_lwt_log.cmo -ppopt syntax/pa_optcomp.cmo -ppopt -let -ppopt 'windows=false' -modules src/unix/lwt_unix.ml > src/unix/lwt_unix.ml.depends
File "src/unix/lwt_unix.ml", line 2074, characters 9-16:
Parse error: [semi] expected after [str_item] (in [implem])
Preprocessing error on file src/unix/lwt_unix.ml
Command exited with code 2.
Compilation unsuccessful after building 110 targets (0 cached) in 00:00:13.
E: Command '/hom/viktore/godis/godi-3.12-spot/bin/ocamlbuild src/core/lwt.cma src/core/lwt.cmxa src/core/lwt.a src/unix/liblwt-unix.a src/unix/dlllwt-unix.so src/unix/lwt-unix.cma src/unix/lwt-unix.cmxa src/unix/lwt-unix.a tests/test.cma tests/test.cmxa tests/test.a tests/unix/main.native -tag debug' terminated with error code 10

Configure gives the following output related to getcpu and affinity:
<cut>
I: Running command 'ocaml discover.ml -ocamlc /hom/viktore/godis/godi-3.12-spot/bin/ocamlc.opt -ext-obj .o -exec-name a.out'
testing for libev: ............................. available
testing for pthread: ........................... available
testing for eventfd: ........................... available
testing for fd passing: ........................ available
testing for sched_getcpu: ...................... available
testing for affinity getting/setting: .......... available
testing for credentials getting: ............... available
Date: 2011-03-15 13:24
Sender: Viktor S. Wold Eide

OK, thanks a lot.
Date: 2011-03-15 12:59
Sender: Jérémie Dimino

Yes, you need the development version of Lwt.
Date: 2011-03-15 11:16
Sender: Viktor S. Wold Eide

There is a problem with compiling the latest version, related to "open
Lwt_react". I am currently using version 2.2.1 of Lwt. Do I need a newer
version?

I only have the following files in lib/ocaml/pkg-lib/lwt :
lwt-react.a lwt-react.cma lwt-react.cmxa

+ ocamlfind ocamlc -c -g -I src -package xmlm -package type-conv.syntax -package lwt.unix -package lwt.syntax.log -package lwt.syntax -package lwt.react -package camlp4.quotations.o -package camlp4.extend -syntax camlp4o -ppopt syntax/pa_obus.cmo -I src -I syntax -I bindings/policykit -I bindings/upower -I bindings/udisks -I bindings/network-manager -I bindings/hal -I bindings/notification -o src/oBus_bus.cmo src/oBus_bus.ml
File "src/oBus_bus.ml", line 12, characters 0-14:
Error: Unbound module Lwt_react
Command exited with code 2.
Compilation unsuccessful after building 112 targets (31 cached) in 00:00:09.
Date: 2011-03-14 22:58
Sender: Jérémie Dimino

Yes, i have added the function (OBus_signal.make_any).
Date: 2011-03-14 21:17
Sender: Viktor S. Wold Eide

OK, thanks. I will have to look more into this.

In an earlier message you mentioned that it might be possible to add a function that allows receiving signals from any objects. Do you still consider that a reasonable approach? I guess that would circumvent the problem?

Regards
Viktor
Date: 2011-03-11 17:48
Sender: Jérémie Dimino

> However, there seems to be an issue with the example. Whenever a
> network interface is activated/deactivated the DHCP information is
> printed, but the information is not up to date. The first time an
> interface is added the information seems correct, but when the same
> interface is activated on another network (where the DHCP information
> received from the server is different), the "old" information is
> output. The "path" remains the same. This is the observed behavior if
> the application is running all the time.

It seems to be a bug in network-manager. When the Dhcp4Config property changes
on a device, a signal is sent from interface "org.freedesktop.NetworkManager.Device.Wired"
while it should be "org.freedesktop.NetworkManager.Device".
Date: 2011-03-10 20:49
Sender: Viktor S. Wold Eide

Hi again,

Thanks a lot for responding quickly and for the patches. The added
functionality seems to do the job. I just tested the example and it
provides the desired information.

However, there seems to be an issue with the example. Whenever a
network interface is activated/deactivated the DHCP information is
printed, but the information is not up to date. The first time an
interface is added the information seems correct, but when the same
interface is activated on another network (where the DHCP information
received from the server is different), the "old" information is
output. The "path" remains the same. This is the observed behavior if
the application is running all the time.

If, on the other hand the application is terminated and then
restarted, the output is correct.

I have not looked into this closely yet, but a "fix" might be to
"re-read" the information whenever a signal is received.

Best regards
Viktor
Date: 2011-03-10 01:13
Sender: Jérémie Dimino

I have just pushed two patches, the first one implements property monitoring for
network-manager and the second add an example showing how to create
a signal (a React one) holding the list of DHCP configurations with their options.
Date: 2011-03-09 16:20
Sender: Jérémie Dimino

> I did a quick test with the full path, but without success. In other
> words, when using the dbus-monitor program in the Ubuntu package, no
> signals are received when the full path is specified, ala:

It is because the path changes every times the network goes down/up. That is why
you have to monitor the Nm_manager.active_connections property.

> OK. Will this added function have to be added to obus itself or
> something that should be done in the application? If this is a small
> addition to obus, a patch would be welcome.

I don't know yet. I need to find a way to integrate it with the
rest of the API.

> The examples provided as part of OBus are really helpful. An
> additional example for this case would potentially save others some
> time in the future.

I am working on it.
Date: 2011-03-09 09:40
Sender: Viktor S. Wold Eide

>> It seems like dbus requires the path to not be specified, i.e. omitted
>> in order to deliver these signals, at least for:
>> type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged'

> No, it is because dbus requires the full path, and the number at the end is part of the path.

I did a quick test with the full path, but without success. In other
words, when using the dbus-monitor program in the Ubuntu package, no
signals are received when the full path is specified, ala:

dbus-monitor --system --monitor type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged',path='/org/freedesktop/NetworkManager/DCHP4Config/178'


I will attach two obus-dump files.

For one of these the path is present in the body for the AddMatch
method_call. In this case nothing is received from dbus when
activating/deactivating the network.

For the other obus-dump file, the path is not present in AddmMatch,
and as can be seen in this case, a signal is received with DHCP4Config
information.


>> Do you think it would make sense to offer an opportunity for receiving
>> such signals, maybe by allowing a proxy to not have a path or for
>> example having
>> path : OBus_path.t option

> Actually the path is the most important part of a proxy as it allow to uniquely identify an object on a peer.
> By the way it would be possible to add a function that allow receiving signals from any objects.

OK. Will this added function have to be added to obus itself or
something that should be done in the application? If this is a small
addition to obus, a patch would be welcome.

The examples provided as part of OBus are really helpful. An
additional example for this case would potentially save others some
time in the future.

Regarding strace as mentioned in the previous comment, sometimes I
find it useful to get in between the OS and the application. But, yes
I agree obus-dump appears more convenient :-)

Regards
Viktor
Date: 2011-03-09 00:50
Sender: Jérémie Dimino

> It seems like dbus requires the path to not be specified, i.e. omitted
> in order to deliver these signals, at least for:
> type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged'

No, it is because dbus requires the full path, and the number at the end is part of the path.

> Do you think it would make sense to offer an opportunity for receiving
> such signals, maybe by allowing a proxy to not have a path or for
> example having
> path : OBus_path.t option

Actually the path is the most important part of a proxy as it allow to uniquely identify an object on a peer.
By the way it would be possible to add a function that allow receiving signals from any objects.
Date: 2011-03-08 22:33
Sender: Viktor S. Wold Eide

> Yes, OBus use a path key/value in the match rule in order to receive only signals coming
> from the given proxy.

It seems like dbus requires the path to not be specified, i.e. omitted
in order to deliver these signals, at least for:
type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged'

I'm not sure, but this might be the case for other signals as well.

Do you think it would make sense to offer an opportunity for receiving
such signals, maybe by allowing a proxy to not have a path or for
example having
path : OBus_path.t option

Thanks for the other suggestions.

Regards
Viktor S. Wold Eide
Date: 2011-03-08 21:44
Sender: Jérémie Dimino

> The number at the end of the path is a number that increases with each
> new signal - a "counter". As an example, see the following output from
> dbus-monitor when the network is deactivated/activated a number of
> times.

OK. After looking at messages sent by Network Manager it seems that the property
org.freedekstop.NetworkManager.ActiveConnections holds the list of active connections.
So you can monitor this property to get objects for connections and then monitor signal
coming from these objects.

Another possibility is to manually add the match rule using OBus_match.export and to
add a message filter with OBus_connection.incoming_filters.

> The following from strace, shows that OBus/the application does
> an AddMatch with a path "key/value". As already mentioned, when the
> path is set in AddMatch, no signals are received from dbus.

Yes, OBus use a path key/value in the match rule in order to receive only signals coming
from the given proxy.

Also note that OBus provides the obus-dump tools to watch messages sent/received by
the application, with an output more readable than strace ;).
Date: 2011-03-08 19:26
Sender: Viktor S. Wold Eide

Hi again,

> Yes. Note that you can also use the Nm_dhcp4_config module:

> Nm_dhcp4_config.properties_changed proxy

Thanks for the advice. I have tried that as well, but it does not seem to make any difference.


> In your example the path in not the same as the one received with
> dbus-monitor, i.e. a '/162' is missing. Is that a copy-paste error ?
> Otherwise the problem may come from here.


The number at the end of the path is a number that increases with each
new signal - a "counter". As an example, see the following output from
dbus-monitor when the network is deactivated/activated a number of
times.


$ dbus-monitor --system --monitor type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged'
signal sender=org.freedesktop.DBus -> dest=:1.1138 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
string ":1.1138"
signal sender=:1.5 -> dest=(null destination) serial=92882 path=/org/freedesktop/NetworkManager/DHCP4Config/166; interface=org.freedesktop.NetworkManager.DHCP4Config; member=PropertiesChanged
array [
dict entry(
string "Options"
variant array [
dict entry(
string "domain_name_servers"
variant string "10.0.0.1"
)
<cut>

signal sender=:1.5 -> dest=(null destination) serial=93003 path=/org/freedesktop/NetworkManager/DHCP4Config/167; interface=org.freedesktop.NetworkManager.DHCP4Config; member=PropertiesChanged
array [
dict entry(
string "Options"
variant array [
dict entry(
string "domain_name_servers"
variant string "10.0.0.1"
)
<cut>

signal sender=:1.5 -> dest=(null destination) serial=93191 path=/org/freedesktop/NetworkManager/DHCP4Config/168; interface=org.freedesktop.NetworkManager.DHCP4Config; member=PropertiesChanged
array [
dict entry(
string "Options"
variant array [
dict entry(
string "domain_name_servers"
variant string "10.0.0.1"
)
<cut>


The following from strace, shows that OBus/the application does
an AddMatch with a path "key/value". As already mentioned, when the
path is set in AddMatch, no signals are received from dbus.


write(7, "l\1\0\1\245\0\0\0\3\0\0\0\210\0\0\0\1\1o\0\25\0\0\0/org/fre"..., 317) = 317
| 00000 6c 01 00 01 a5 00 00 00 03 00 00 00 88 00 00 00 l....... ........ |
| 00010 01 01 6f 00 15 00 00 00 2f 6f 72 67 2f 66 72 65 ..o..... /org/fre |
| 00020 65 64 65 73 6b 74 6f 70 2f 44 42 75 73 00 00 00 edesktop /DBus... |
| 00030 02 01 73 00 14 00 00 00 6f 72 67 2e 66 72 65 65 ..s..... org.free |
| 00040 64 65 73 6b 74 6f 70 2e 44 42 75 73 00 00 00 00 desktop. DBus.... |
| 00050 03 01 73 00 08 00 00 00 41 64 64 4d 61 74 63 68 ..s..... AddMatch |
| 00060 00 00 00 00 00 00 00 00 06 01 73 00 14 00 00 00 ........ ..s..... |
| 00070 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 6f 70 2e org.free desktop. |
| 00080 44 42 75 73 00 00 00 00 08 01 67 00 01 73 00 00 DBus.... ..g..s.. |
| 00090 09 01 75 00 00 00 00 00 a0 00 00 00 74 79 70 65 ..u..... ....type |
| 000a0 3d 27 73 69 67 6e 61 6c 27 2c 73 65 6e 64 65 72 ='signal ',sender |
| 000b0 3d 27 3a 31 2e 35 27 2c 69 6e 74 65 72 66 61 63 =':1.5', interfac |
| 000c0 65 3d 27 6f 72 67 2e 66 72 65 65 64 65 73 6b 74 e='org.f reedeskt |
| 000d0 6f 70 2e 4e 65 74 77 6f 72 6b 4d 61 6e 61 67 65 op.Netwo rkManage |
| 000e0 72 2e 44 48 43 50 34 43 6f 6e 66 69 67 27 2c 6d r.DHCP4C onfig',m |
| 000f0 65 6d 62 65 72 3d 27 50 72 6f 70 65 72 74 69 65 ember='P ropertie |
| 00100 73 43 68 61 6e 67 65 64 27 2c 70 61 74 68 3d 27 sChanged ',path=' |
| 00110 2f 6f 72 67 2f 66 72 65 65 64 65 73 6b 74 6f 70 /org/fre edesktop |
| 00120 2f 4e 65 74 77 6f 72 6b 4d 61 6e 61 67 65 72 2f /Network Manager/ |
| 00130 44 48 43 50 34 43 6f 6e 66 69 67 27 00 DHCP4Con fig'. |


Regards
Viktor S. Wold Eide
Date: 2011-03-08 18:30
Sender: Jérémie Dimino

Hi,

> I might be misunderstanding something, but it appears that a proxy is needed in order to create the signal descriptor for these signals, via:
>
> OBus_signal.make Nm_interfaces.Org_freedesktop_NetworkManager_DHCP4Config.s_PropertiesChanged proxy

Yes. Note that you can also use the Nm_dhcp4_config module:

Nm_dhcp4_config.properties_changed proxy

> When a path "key" is present in AddMatch , no signals are sent out on the dbus. As an example, no signals are received if the path "key" is present when using dbus-monitor, ala:
>
> dbus-monitor --system --monitor type='signal',interface='org.freedesktop.NetworkManager.DHCP4Config',member='PropertiesChanged',path='/org/freedesktop/NetworkManager/DCHP4Config'

In your example the path in not the same as the one received with dbus-monitor, i.e. a '/162' is missing. Is that a copy-paste error ? Otherwise the problem may come from here.

Changes:

Field Old Value Date By
File Added116: obus-dump-without-path.txt2011-03-09 09:40viktor
File Added115: obus-dump-with-path.txt2011-03-09 09:40viktor