Shill emits unnecessary ProperyChanged for IPConfigs on org.chromium.flimflam.Device interface when device is disconnected.
Reported by
printe...@chromium.org,
Mar 31 2016
|
|||||
Issue description
When there is an interface with IPv6 enabled that accepts RA (/proc/sys/net/ipv6/conf/<interface>/accept_ra is 1) and uses Privacy Extensions (/proc/sys/net/ipv6/conf/<interface>/use_tempaddr is 2), if the cable is unplugged (for Ethernet) or the interface is disabled for (Wifi) then an unnecessary ProperyChanged signal for IPConfigs on org.chromium.flimflam.Device interface is emitted.
The signal contains a path to an IPConfig that is destroyed quickly after, and if there is something that monitors these signals and will try to get the properties for this IPConfig will get the error:
Failed to call method: org.chromium.flimflam.IPConfig.GetProperties: object_path= /ipconfig/eth0_8_ip: org.freedesktop.DBus.Error.UnknownObject: Method "GetProperties" with signature "" on interface "org.chromium.flimflam.IPConfig" doesn't exist
Run
dbus-monitor --system 'type=signal,member=PropertyChanged,interface=org.chromium.flimflam.Device,arg0=IPConfigs'
to check the emitted notifications.
Digging a little bit in the shill code, I saw that this happens because:
1. When the interface is disconnected Device::DestroyIPConfig() is called, which will free and destroy all the IPConfigs for the device.
2. Kernel will send RT netlink messages informing about removal of the IPv4/IPv6 addresses for the device.
3. Because of the settings in the first paragraph, the kernel created two IPv6 addresses for the device: a "global mngtmpaddr dynamic" from the prefix and the MAC address and a "global temporary dynamic" one which has priority because of the Privacy Extensions. The message for the removal of the temporary one gets first.
4. RTNLHandler::ParseRTNL() calls DeviceInfo::AddressMsgHandler which calls Device::OnIPv6AddressChanged(). It will create a new IPConfig and will invoke UpdateIPConfigsProperty() which will emit the signal.
5. The IPConfig is then destroyed.
I attached a small patch that fixes this problem, but I need someone more experienced to look at this issue and if this in fact solves the problem.
,
Apr 5 2016
,
Apr 5 2016
I don't think that change by itself might work out under all circumstances. At the very least, if a change were to be made, I'd assume it would be related to sending of the event, and not related to the bookkeeping that the Device does. Frankly speaking, at the time that the IPConfigs are sent, everything is valid, no matter how short-lived. Fixing this in shill only addresses the race condition you described (on shutdown) but won't address any other situations where an IPConfig (or Device) might suddenly go away. It might be better to fix this in the client application.
,
Apr 6 2017
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue. The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25
,
Jan 15
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by kolos@chromium.org
, Apr 5 2016