You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
setup() never binds the socket: provisioning packet leaves via the default route on multi-homed hosts #844
On a host with more than one active interface, an unbound socket sending to 255.255.255.255 leaves via the default route, not via the interface attached to the device's BroadlinkProv AP. The call returns successfully, nothing is raised, and the device is simply never provisioned — a silent failure that is very hard to attribute.
This is inconsistent with discover() / xdiscover(), which already expose local_ip_address for exactly this reason.
How it shows up in practice
Provisioning a device from a laptop that is simultaneously on the device AP (Wi-Fi) and on a USB/Ethernet uplink is a completely ordinary setup — you need the second interface to keep working while the Wi-Fi is occupied by the AP. In that configuration setup() never reaches the device.
Diagnosed on macOS with Wi-Fi on the device AP (192.168.10.2) and an active USB tether holding the default route. setup() reported success; the device never associated. Binding the socket to the Wi-Fi address and sending to the subnet broadcast made it work on the first try.
Steps to reproduce
Host with two active interfaces, default route on interface B.
Put a Broadlink device in AP mode; connect interface A to BroadlinkProv (host gets 192.168.10.x).
Call broadlink.setup(ssid, password, 3).
Packet is transmitted on interface B. Device is never configured, no error raised.
Suggested fix
Accept an optional local address and bind, mirroring discover():
Activity