ASUS Wireless "General" Tab 2.4 GHz band setting
The Advanced Settings → Wireless → General page is where an ASUS router defines the radio-level identity, PHY behavior, and security baseline of each wireless band.
At a Glance: The General Tab
1. Field-by-Field Explanation
1.1 Band
- Function: On concurrent dual-band ASUSWRT builds, the entire General page is per-radio. This selector chooses which radio (2.4 GHz or 5 GHz) the form displays and edits; changing it reloads the page with that radio's stored values.
- Why it matters: SSID, mode, channel, and security are stored independently per radio.
- Guidance: Configure each band intentionally. Mirror SSID and security for a single-network experience, or split names if you want explicit control over which band devices use.
- Note: On genuinely single-band 802.11n units, this selector is fixed or absent.
1.2 Network Name (SSID)
- Function: The service set identifier advertised in beacons and probe responses; the name clients see when scanning. Limited to 32 bytes, case-sensitive.
- Hidden role: The SSID is also the salt in the PBKDF2 derivation of the pairwise master key (PMK) from your passphrase. Renaming the network therefore changes key derivation and forces clients to re-provision profiles.
- Guidance:
- Avoid personally identifying or location-revealing names.
- Avoid emoji and exotic Unicode; some IoT provisioning stacks mishandle them.
- Keep names distinct from neighbors' to simplify troubleshooting and roaming decisions.
1.3 Hide SSID
- Function: Transmits a zero-length SSID element in beacons ("closed network"), forcing clients to send directed probe requests containing the network name.
- Reality check: This is obscurity, not security. The SSID still appears in probe requests, association frames, and any packet capture; discovery tools recover it in seconds.
- Costs: Slower initial connections, increased probe traffic (battery and privacy impact on clients), and broken auto-join behavior on some IoT and mobile devices.
- Verdict: Leave at No. Enable only for cosmetic crowd-control in dense office environments.
1.4 Wireless Mode
- Function: Defines which 802.11 PHY generations may associate on this radio.
- Implications of N Only: N Only improves efficiency by rejecting legacy b/g clients and is appropriate when all devices support 802.11n. No station can drag the BSS down to 1–11 Mbps CCK rates, and protection overhead disappears. The trade-off is that legacy b/g-only devices (older cameras, plugs, sensors) cannot join.
- Companion checkboxes:
- Optimized for Xbox: A vendor compatibility toggle, thinly documented by ASUS and widely understood to adjust WMM power-save (APSD) handling so Xbox Live sessions stop dropping over Wi-Fi. Leave unchecked unless you are actively troubleshooting console connectivity.
- b/g Protection: Forces ERP protection (CTS-to-self / RTS-CTS) so 802.11b radios can detect g/n transmissions and defer correctly. In mixed modes the firmware engages protection automatically; in N Only no legacy stations can exist, so the control is moot (grayed out on some builds). Forcing it on in mixed environments adds measurable overhead.
1.5 Channel Bandwidth
- Function: Sets the channel bond width: 20 MHz, 40 MHz, or (on some builds) an auto 20/40 mode.
- Theory vs. practice: 40 MHz doubles HT data rates (e.g., a 2-stream client moves from ~144 Mbps to ~300 Mbps MCS ceilings), but on 2.4 GHz the band accommodates roughly one clean 40 MHz bond before overlapping neighbors. Resulting co-channel interference triggers retransmissions that erase the theoretical gain.
- Guidance:
- 20 MHz on 2.4 GHz in any multi-tenant or urban environment. 20 MHz is the more stable choice on 2.4 GHz because only three non-overlapping channels exist (1, 6, and 11).
- Auto 20/40 mode: Some client device may have difficulty connecting to the wireless network in this mode.
- 40 MHz mode: Some client devices may have difficulty connecting to the wireless network in this mode or they may go through stability issues in this mode.
- Verdict: The 20 MHz is the stable and most compatible with client devcies.
1.6 Control Channel
- Function: The center channel on which the BSS beacons; with 40 MHz bonds it also anchors the control/secondary channel pair.
- Auto mode: The AP scans at boot and selects the least congested channel; the yellow status text ("Current control channel: 11") reports the live result of that selection.
- Manual mode: Region-gated list — 1–11 (FCC), 1–13 (ETSI), with channel 14 restricted to 802.11b in Japan.
- Guidance:
- Survey the RF environment with an analyzer app.
- Pin the radio to one of the non-overlapping trio — 1, 6, or 11 — with the least neighbor traffic.
- Re-survey periodically; neighbor networks change. Auto is acceptable at boot, but a pinned channel gives reproducible behavior for roaming and mesh deployments.
1.7 Authentication Method
- Function: Selects the key-management and access-control framework for the BSS.
- Selecting the WPA2-Personal provides best security and compatibility with client devices.
1.8 WPA Encryption
- Function: Chooses the cipher for unicast (pairwise) and group-addressed frames.
- Verdict: AES only. Any TKIP presence silently downgrades throughput network-wide.
1.9 WPA Pre-Shared Key
- Function: The shared secret (8–63 ASCII characters, or 64 hex digits) that, combined with the SSID via PBKDF2-SHA1 (4096 iterations), produces the 256-bit PMK. The PMK seeds the 4-way handshake that derives the per-session pairwise key (PTK) and the group key (GTK).
- Strength guidance:
- Length beats complexity classes: prefer 20+ random characters over short symbol-heavy strings.
- Avoid dictionary phrases, song lyrics, and reused passwords.
- Store in a password manager; distribute out-of-band.
- Operational reality: A PSK is shared trust — anyone who ever learned it retains access until rotation, and traffic cannot be attributed per user (an enterprise 802.1X deployment solves both problems).
1.10 Group Key Rotation Interval
- Function: Interval, in seconds, at which the AP regenerates the Group Temporal Key (GTK) used to encrypt broadcast and multicast traffic (ARP, mDNS, group-addressed data).
- Trade-offs:
- Shorter interval: narrower exposure window if a GTK is ever recovered; more rekey handshakes, which some low-cost IoT Wi-Fi stacks handle poorly.
- Longer interval: less rekey churn; marginally wider exposure window.
- Observed value: 14400 s (4 hours). Common factory default is 3600 s. Both are defensible; avoid extremes — sub-300-second values cause needless churn, and 0 (which disables rotation on some builds) is not recommended.
- Common Values: Typical values range from 3600 (1 hour) to 86400 (24 hours). For example:
- 3600 seconds (1 hour): Updates the GTK hourly.
- 1800 seconds (30 minutes): Updates the GTK every half hour.
- 7200 seconds (2 hour): Updates the GTK every 2 hour.
- 14400 seconds (4 hour): Updates the GTK every 4 hour.
- 86400 seconds (24 hours): Updates the GTK daily.
- Note: Rekeys are transparent to healthy clients; unexpected drops after changing this value usually point at fragile client firmware.
2. Recommended Baseline Configuration
- Band: 2.4 GHz
- SSID: unique, non-identifying, ≤32 bytes, plain ASCII.
- Hide SSID: No.
- Wireless Mode: N Only on 2.4 GHz (drop to G/N Mixed only if legacy IoT devices demand it); both companion checkboxes unchecked.
- Channel bandwidth: 20 MHz on 2.4 GHz.
- Control Channel: Auto, or pinned to 1, 6, or 11 after an RF survey.
- Authentication Method: WPA2-Personal.
- WPA Encryption: AES.
- WPA Pre-Shared Key: rotated, random, ≥20 characters, manager-stored.
- Group Key Rotation Interval: 3600–14400 seconds.
- Apply, then validate connectivity and throughput.