Problem
The DD-WRT binding's radio enabled channel can report ON when the radio is actually disabled, and some radio control commands do not perform the firmware-specific operation needed to stop or restore transmission.
Observed problems include:
- Radio implementations hard-code the enabled state instead of reading it from the device.
- Command failures can be reported as success because control uses an output helper that does not propagate a non-zero exit status.
- OpenWrt needs the logical wireless device resolved from the interface and controlled with
/sbin/wifi; changing only the Linux interface state does not reliably restore the AP.
- Tomato can expose Broadcom radios as
eth1/eth2 through NVRAM rather than wl0/wl1, so the current fixed interface list misses radios.
- FreshTomato's
wl channel can report a 40 MHz center channel rather than the user-visible control channel.
Expected behavior
- The
enabled channel reflects the device's actual radio/interface state.
- Enable and disable use the appropriate command for DD-WRT, OpenWrt, and Tomato devices.
- Failed device commands do not optimistically update the openHAB state.
- Tomato radio discovery follows the NVRAM interface mapping and reports the control channel.
Validation
The behavior was reproduced and tested on:
- DD-WRT on a Linksys WRT3200ACM (Marvell)
- OpenWrt access points
- FreshTomato 2026.1 on a Netgear WNR3500L v2
- Tomato 1.28 on a Netgear WNR3500L v2
DD-WRT Marvell, OpenWrt, and FreshTomato AP-mode radios were verified both through device state and over-the-air visibility. On Tomato 1.28 in wet wireless-client mode, disabling the only client radio necessarily removes management connectivity and a remote enable does not reliably reassociate it; that topology requires an out-of-band recovery plan and should not be treated as successful AP-mode validation.
Original report and screenshots: ballle98#51
Problem
The DD-WRT binding's radio
enabledchannel can reportONwhen the radio is actually disabled, and some radio control commands do not perform the firmware-specific operation needed to stop or restore transmission.Observed problems include:
/sbin/wifi; changing only the Linux interface state does not reliably restore the AP.eth1/eth2through NVRAM rather thanwl0/wl1, so the current fixed interface list misses radios.wl channelcan report a 40 MHz center channel rather than the user-visible control channel.Expected behavior
enabledchannel reflects the device's actual radio/interface state.Validation
The behavior was reproduced and tested on:
DD-WRT Marvell, OpenWrt, and FreshTomato AP-mode radios were verified both through device state and over-the-air visibility. On Tomato 1.28 in
wetwireless-client mode, disabling the only client radio necessarily removes management connectivity and a remote enable does not reliably reassociate it; that topology requires an out-of-band recovery plan and should not be treated as successful AP-mode validation.Original report and screenshots: ballle98#51