RutOS firmware CAP7_R_00.07.21.3 does not support Multi-Link Operation (MLO), so there is no MLO menu or enable control to locate on the CAP700. Do not treat an absent MLO option as a failed upgrade or hidden configuration. The reported information also gives no location or defined behavior for a Refresh Interval option; identify the page and function associated with that label before changing it.
Support Status in CAP7_R_00.07.21.3
| Item | Status | Engineering action |
|---|---|---|
| Firmware | CAP7_R_00.07.21.3 |
Use this exact version when checking the installed build and release notes. |
| MLO | Not supported in current RutOS firmware | Stop searching for an enable switch, hidden page, or alternate wireless mode. |
| Wi-Fi 7 hardware | Wi-Fi 7-capable products exist, including the ALTOS series | Separate radio capability from firmware feature availability. |
Refresh Interval |
Its page, purpose, range, and relationship to MLO are unspecified | Record the exact page and adjacent fields, then consult the matching product documentation or official support channel. |
The decisive point is the distinction between hardware capability and implemented firmware functionality. A Wi-Fi 7-capable radio does not automatically make every Wi-Fi 7 feature configurable. RutOS must contain the required radio-driver support, link-management logic, security integration, configuration interface, status reporting, and recovery behavior before MLO can be exposed as an operational feature.
Why the MLO Control Is Missing
MLO allows a compatible wireless device to coordinate traffic over multiple links. That coordination is more than presenting multiple radios or bands in the interface. The access point and client must negotiate compatible operation, maintain link state, apply security correctly, steer traffic, and recover when an individual link changes or fails.
In this firmware generation, development is focused on core Wi-Fi 7 stability and functionality. Consequently, the absence of an MLO control is expected product behavior. Reinstalling the same firmware, resetting the configuration, changing browsers, or repeatedly rescanning wireless settings will not create a feature that the firmware does not implement.
This also explains why Wi-Fi 7 branding alone is not an adequate acceptance criterion. If a project depends on MLO for latency or throughput reliability, the acceptance requirement must explicitly name MLO and require proof that the installed firmware exposes and operates it.
Diagnostic Sequence for an Apparently Missing MLO Option
-
Confirm the device and firmware identity. Read the product model and installed firmware from the device status or system information page. Compare the complete firmware token with
CAP7_R_00.07.21.3; do not rely on a downloaded filename or an intended upgrade package. - Review the normal wireless configuration and status pages. Document the available radio, network, security, and client controls. A missing MLO field on this build is expected, but the record prevents confusion with a page-rendering or permissions problem.
- Check whether the requirement is truly MLO. Define the required outcome: lower latency, higher aggregate throughput, link resilience, or all three. Those goals affect test design and cannot be validated merely by confirming that clients can connect.
- Verify both ends of the proposed link. Future use of MLO will require compatible access-point firmware and compatible client behavior. Record the client hardware, driver, operating system, negotiated link state, and test conditions without assuming that a Wi-Fi 7 label proves MLO operation.
- Check official release notes and the changelog for later builds. Look for an explicit MLO support statement tied to the applicable product and firmware. A generic stability entry or Wi-Fi 7 reference is not equivalent to feature support.
- Escalate only with reproducible identification data. Provide the exact product, firmware token, configuration export as permitted by site policy, screenshots of the relevant wireless pages, and the operational requirement to the manufacturer’s official support channel.
What to Do Instead of Enabling MLO
There is no configuration procedure that enables MLO in CAP7_R_00.07.21.3. Treat this as a capability gap and choose a project response based on schedule and performance risk.
| Project condition | Recommended response |
|---|---|
| MLO is mandatory for acceptance | Do not approve this firmware as meeting the requirement. Request a documented product and firmware roadmap through an official support channel, or select a platform with explicitly documented MLO support. |
| MLO is desirable but not mandatory | Commission the available Wi-Fi functions and test the actual latency, throughput, and stability against the application limits. |
| A future firmware may add MLO | Track release notes and changelogs, then repeat qualification when a release explicitly lists support for the applicable device. |
| Deployment cannot wait | Engineer around the measured performance of the current single-link operation instead of budgeting performance from an unavailable feature. |
Preserve the working configuration before any future firmware change. When an MLO-capable build is eventually documented, evaluate it in a test environment before production deployment because wireless behavior, client compatibility, roaming, and recovery all affect the application.
Handling the Refresh Interval Question
Refresh Interval is not sufficiently identified by the label alone. Interfaces commonly use refresh intervals for periodic status-page updates, scans, monitoring data, or other housekeeping functions. Those functions have different performance consequences, and none should be assumed to control MLO.
- Capture the full page name, navigation path, nearby field labels, current value, and selectable range.
- Observe whether changing the value updates only displayed data or initiates wireless activity. Use device diagnostics and traffic measurements rather than judging from the label.
- Restore the original value if the setting’s effect remains unclear.
- Check the documentation for that exact firmware and page, or submit the captured context to official support.
Do not use the refresh setting as a workaround for missing MLO. A display refresh, scan interval, or monitoring poll cannot add multi-link negotiation to a firmware stack that lacks MLO support.
Verification and Recurring Pitfalls
Verification has two stages. First, verify present capability: the installed build is CAP7_R_00.07.21.3, ordinary wireless service operates as configured, and no project document incorrectly marks MLO as available. Second, establish a future acceptance test for any release that explicitly adds MLO.
A future test should confirm that the configuration interface exposes MLO, both endpoints report multi-link operation, and measured application traffic meets latency, throughput, and interruption limits under controlled conditions. Include link degradation or loss in the test if reliability is the reason for requiring MLO. An MLO menu alone proves configuration exposure, not successful multi-link traffic.
Recurring errors include equating Wi-Fi 7 hardware with complete Wi-Fi 7 firmware support, mistaking a missing option for a damaged installation, treating release-note wording about general stability as an MLO announcement, and changing unrelated timing controls in search of hidden functionality. Avoid these errors by tying every acceptance decision to the exact product, firmware, client, negotiated state, and measured application result.
FAQ
Does RutOS CAP7_R_00.07.21.3 support MLO?
No. MLO is not supported in the current RutOS firmware, including CAP7_R_00.07.21.3.
Where is the MLO setting on the CAP700?
There is no MLO setting to enable in this firmware because the feature is not implemented. A reset or reinstall of the same build will not add the control.
Does Wi-Fi 7 hardware guarantee Multi-Link Operation?
No. The hardware, firmware, driver, and client must all support compatible MLO operation; Wi-Fi 7-capable hardware alone does not establish feature availability.
Is Refresh Interval the control for MLO?
No relationship is identified. Record the exact page and surrounding fields before changing Refresh Interval, and verify its function in the matching documentation or through official support.
How do I know when RutOS adds MLO support?
Monitor official firmware release notes and changelogs for an explicit MLO entry tied to the applicable product. After release, verify the configuration control, negotiated multi-link state, and measured application performance.