New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 598493 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

shill: wake-on-WiFi D-Bus API methods succeed even if packet feature is disabled

Reported by samueltan@chromium.org, Mar 29 2016

Issue description

shill's D-Bus API methods handling the adding and removing of whitelisted IP addresses (i.e. WakeOnWiFi::AddWakeOnPacketConnection, WakeOnWiFi::RemoveWakeOnPacketConnection, WakeOnWiFi::RemoveAllWakeOnPacketConnections) will update |wake_on_packet_connections_| and return success, even if the "packet" feature is disabled. This is misleading to the remote service that called any of these methods, since shill will not actually program the NIC to wake on any of the IP addresses registered in |wake_on_packet_connections_| during suspend.

shill should instead explicitly return failure on these D-Bus calls if the packet feature is not enabled. This can be done by checking the return value of WakeOnWiFi::WakeOnWiFiPacketEnabledAndSupported(), instead of checking |wake_on_wifi_triggers_supported_| alone.
 
Cc: malaykeshav@chromium.org
Sameer, feel free to assign this bug to me if you'd like. This might also make a good starter bug for anyone looking to get acquainted with shill's WakeOnWiFi implementation.
 crbug.com/548298  is closely related to this bug. Chrome unnecessarily calls shill's wake-on-WiFi D-Bus API methods even when the packet feature is not enabled, and shill silently accepts these calls.
Components: OS>Systems>Network
Status: Assigned (was: Untriaged)

Sign in to add a comment