[poornakumar-pk]

Reason for change: It prevents the STA connection attempt when the candidate is invalid
Test Procedure: check XLE not use same channel while it is in the nop_started state
Risks:
Priority: P1
Signed-off-by: poornakumar_mezhiselvam@comcast.com

[Copilot]

🟡 Changes recommended

The new validation can reject valid backhaul candidates because of incorrect 6 GHz frequency conversion and overly restrictive bandwidth checks.

2 open issues

• Misclassifies low 6 GHz frequencies during channel conversion · New
• Rejects compatible APs when advertised bandwidth exceeds local width · New

What changed in this PR

Backports the LTE-3100 DFS/NOP validation from PR #1490 to 8.7_p1b, checking mesh backhaul candidates before attempting a connection.

Changes:

• Validates cached and scanned candidates against runtime radio parameters before wifi_hal_connect().
• Clears or skips rejected candidates and reschedules connection selection.
• Extends NOP checks to 160 MHz operating blocks with non-DFS primary channels.

File	Description
source/​utils/​wifi_util.c	Expands the condition for operating-block NOP validation.
source/​core/​services/​vap_svc_mesh_ext.c	Adds candidate validation and rejection handling before backhaul connections.

_{Review effort: Balanced}

[mateuszCieslak-GL]

Valid. The old converter turns 5955/5975 MHz into 191/195, so 6 GHz parents on primary 1/5 are rejected. Main already has the band-aware convert_freq_to_channel() from #1542; this will be fixed in a future PR.

[mateuszCieslak-GL]

Not reachable on rdk-wifi-hal platforms. The HAL never fills radiocap.channelWidth, and move_radio_capability() defaults 5 GHz to 20/40/80/160, so a 160 MHz parent always passes.

[Copilot]

🟡 Changes recommended

Allocation failure in the new validation path can stall backhaul recovery without scheduling a retry.

3 open issues

• Misclassifies low 6 GHz frequencies during channel conversion
• Allocation failure leaves backhaul recovery without a retry · New
• Rejects compatible APs when advertised bandwidth exceeds local width

_{Review effort: Balanced}

[mateuszCieslak-GL]

Valid, minor. #1542 calls schedule_connect_sm() on this path, and the NOP-only check proposed there drops the allocation altogether.

[mateuszCieslak-GL]

@poornakumar-pk please hold this for 8.7, if possible (CC: @gsathish86 ).
The gateway runs the full radio-config validator against the parent, using the extender's own DfsEnabled. With DFS disabled on the extender (the default until the DFS RFC is enabled), every parent whose operating block touches channels 52–144 is rejected, not only channels in NOP. That includes the default primary channel 44 when the parent runs 160 MHz, because 36–64 contains 52–64. Before this change the extender connected in that case. It shows up as Invalid channel 44 ... bw = 0x8 (or DFS is disabled ! Failed setting DFS channel <ch>) followed by rejecting backhaul candidate.

During a staged DFS rollout, gateways and extenders won't get the RFC at the same time. Extenders that haven't been switched yet would lose 5 GHz backhaul to gateways that have been. Please limit the gate to the NOP state of the parent's channel block (proposal on #1542 to follow), or confirm that rejecting DFS parents with local DFS off is intended and make that an explicit, logged check.