[WiFi] Channel Width Grouping — Client-side Implementation Complete

[AustinChangLinksys]

Problem

PossibleChannels returns a flat list with no grouping by channel width.

Current behavior: TR-181 Device.WiFi.Radio.{i}.PossibleChannels returns all available channels as a flat list without indicating which channels are valid at 40MHz/80MHz/160MHz/320MHz.

Workaround: 🟢 Client-side computable using IEEE 802.11 bonding rules.

Solution Implemented

Client-side implementation completed in PR #691.

File: lib/page/wifi_settings/services/wifi_channel_bonding.dart

Features

• IEEE 802.11 standard channel bonding rules for all bands:
  • 2.4GHz: 20MHz / 40MHz bonding pairs
  • 5GHz: 20MHz / 40MHz / 80MHz / 160MHz bonding groups
  • 6GHz: 20MHz / 40MHz / 80MHz / 160MHz / 320MHz (dynamically generated)
• computeChannelsPerBandwidth() function computes valid primary channels per bandwidth
• Bidirectional wireless mode ↔ bandwidth constraints

Status

✅ Resolved — Client-side alternative implemented, no firmware support needed.

Related

• Implementation PR: feat: SSE reliability, WiFi advanced mode, demo mode & SelectAutoComplete migration #691
• Parent tracker: [WiFi] WiFi Settings Complete Support #791
• Master tracker: [MASTER] USP/TR-181 Integration Status - Root Tracker #788

[AustinChangLinksys]

Resolved via client-side implementation in PR #691. IEEE 802.11 channel bonding rules are computed locally using wifi_channel_bonding.dart.