GNOME Bugzilla – Bug 725657
No info emitted about new IPv4Config when device is activated
Last modified: 2020-11-12 14:31:25 UTC
See the output from dbus-monitor, where you can see that a device is activated, but IPv4Config/IPv6Config is updated only for its active connection and not also for the device. My version of NM is NetworkManager-0.9.9.0-31.git20131003.fc20.x86_64 signal sender=:1.266 -> dest=(null destination) serial=5896 path=/org/freedesktop/NetworkManager/Devices/2; interface=org.freedesktop.NetworkManager.Device; member=StateChanged uint32 100 uint32 90 uint32 0 signal sender=:1.266 -> dest=(null destination) serial=5909 path=/org/freedesktop/NetworkManager/Devices/2; interface=org.freedesktop.NetworkManager.Device.Wireless; member=PropertiesChanged array [ dict entry( string "State" variant uint32 100 ) dict entry( string "StateReason" variant struct { uint32 100 uint32 0 } ) dict entry( string "ActiveAccessPoint" variant object path "/org/freedesktop/NetworkManager/AccessPoint/3" ) dict entry( string "Bitrate" variant uint32 6000 ) ] signal sender=:1.266 -> dest=(null destination) serial=5910 path=/org/freedesktop/NetworkManager/ActiveConnection/4; interface=org.freedesktop.NetworkManager.Connection.Active; member=PropertiesChanged array [ dict entry( string "State" variant uint32 2 ) dict entry( string "Dhcp6Config" variant object path "/" ) dict entry( string "Dhcp4Config" variant object path "/org/freedesktop/NetworkManager/DHCP4Config/4" ) dict entry( string "Ip6Config" variant object path "/org/freedesktop/NetworkManager/IP6Config/5" ) dict entry( string "Ip4Config" variant object path "/org/freedesktop/NetworkManager/IP4Config/5" ) ]
I think Thomas has a patch that fixes this on some branch he's working on?
Not sure I understand correctly, but... Already for a while now [1], the IP[46]Config instance of a device stays the same, when the config changes. Instead, the device keeps always the same IP[46]Config instance, but the properties ~inside~ the config change. I think what you are seeing works as intended. [1] http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=db9b7e10aca5456ec4960b75617e032209b98bc1
The problem is that we don't get the path to IP[46]Config, because it's not emitted when device is activated in PropertiesChanged, only when the device is deactivated and in this case the path is removed, see: signal sender=:1.266 -> dest=(null destination) serial=7306 path=/org/freedesktop/NetworkManager/Devices/2; interface=org.freedesktop.NetworkManager.Device.Wireless; member=PropertiesChanged array [ dict entry( string "Ip6Config" variant object path "/" ) dict entry( string "Ip4Config" variant object path "/" ) ]
Thomas: I thought I remembered some patch where you added some missing g_object_notify()s? Maybe it wasn't you...
(In reply to comment #3) > The problem is that we don't get the path to IP[46]Config, because it's not > emitted when device is activated in PropertiesChanged, only when the device is > deactivated and in this case the path is removed, see: > I still don't understand the problem. The IP[46]Config property does (usually) *not* change when the device gets activated. IOW, the object path does not change, so you don't receive a PropertiesChanged signal. Actually, you might get some spurious PropertiesChanged signals, although the path did not change... (but that shouldn't hurt).
(In reply to comment #5) > (In reply to comment #3) > > Actually, you might get some spurious PropertiesChanged signals, although the > path did not change... (but that shouldn't hurt). Ok, I checked again :) The path does change, but I get the correct signals -- but note, that I get spurious events for paths that did not really change... but eventually, I get the right signal when needed.
*** Bug 729828 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > > Actually, you might get some spurious PropertiesChanged signals, although the > > path did not change... (but that shouldn't hurt). > > Ok, I checked again :) > > The path does change, but I get the correct signals -- but note, that I get > spurious events for paths that did not really change... but eventually, I get > the right signal when needed. With what version was that?
It was with some packaged snapshot of NM 0.9.9.0 for Fedora 20, but it's also possible that the problem was there even before (eg in NM 0.9.8.x).
(In reply to comment #9) > It was with some packaged snapshot of NM 0.9.9.0 for Fedora 20, but it's also > possible that the problem was there even before (eg in NM 0.9.8.x). Thanks, but I was asking Thomas about _his_ version, the one he used to try to reproduce this bug but couldn't. I think it _is_ fixed somewhere on master, but I am too lazy to check myself. (And we need to cope with buggy versions anyway.)
Sorry, I can't remember. If I did not screw up, I should have tested the stable Fedora20 package from March 17, 2014. Will look into this again
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).