A working configuration that turns an Asus RT-N12 D1 (Broadcom BCM53572) running
FreshTomato Max 2026 into a transparent Wi-Fi repeater: WET mode on the primary
radio for the uplink, plus a virtual AP (wl0.1) broadcasting the same SSID for clients.
Same SSID on both routers means seamless roaming — clients pick the stronger AP by RSSI on their own. The repeater is a transparent bridge, so every client gets its address from the main router's DHCP and appears in its client list.
This took a lot of trial and error. Everything that cost me time is written down here.
If you arrived from a search engine, these are probably what you need. None of them produce an error message — the configuration simply does not work.
1. regdomain=UA silently breaks WET association on BCM53572.
wl0 sees the BSSID but never associates. Set wl_country_code=US and
wl0_country_code=US. This one cost me the most time, because the scan list looks
perfectly normal while the association never completes.
2. MAC collision between wl0.1 and wl0.
By default Tomato copies the eth1 MAC onto the virtual AP. Clients then fail the WPA
handshake with no useful diagnostics. Fix: nvram set wl0.1_hwaddr="" followed by a
reboot — Tomato generates a correct locally-administered MAC by itself.
3. The driver reports wl0.1 as Mode: Managed even when the interface really is
in AP mode. This is cosmetic. Check the actual state with wl -i wl0.1 ap, which must
return 1.
4. Tomato does not bring the virtual AP up while wl0 is in WET mode.
It has to be forced with wl commands from the Init script after boot. This is what
init-script.sh is for.
5. On the RT-N12 D1 the LAN switch is vlan0, not vlan1.
lan_ifnames must be vlan0 eth1 wl0.1. Using vlan1 — which is correct on most other
Broadcom models — is the most common reason a configuration "almost works".
6. NTP needs IP addresses, not hostnames.
/etc/resolv.conf points into the read-only /rom, so name resolution for ntpd fails.
The setup script uses Cloudflare and Google addresses directly.
7. Reset the right way: hold Reset for 30 seconds with the power ON. Do not power off, hold Reset, then power on — that enters CFE Rescue Mode, and from there only Asus Firmware Restoration or a TFTP flash will bring the device back.
- Model: Asus RT-N12 D1 (Broadcom BCM53572, 8 MB flash, 28 MB RAM, 32 KB NVRAM)
- Firmware: FreshTomato Max 2026
- Interfaces:
eth0= LAN switch controller,eth1= wireless radio,vlan0= LAN ports
Main router (192.168.0.1)
^
| WET link (wl0 / eth1)
|
RT-N12 (192.168.0.2, br0)
|
+-- virtual AP wl0.1, same SSID --> clients
DHCP on the repeater is disabled (dhcp_enable_x=0) — the main router serves every
client through the transparent bridge. Because WET passes client MAC addresses through
unchanged, all of them remain visible on the main router.
| File | What it is |
|---|---|
nvram-setup.sh |
Full configuration from scratch, pasted into Tools → System Commands |
init-script.sh |
Administration → Scripts → Init — forces AP mode on wl0.1, then turns the LEDs off |
diagnostics.sh |
Commands for checking the uplink, the AP and the bridge |
Replace YOUR_SSID and YOUR_WIFI_PASSWORD with the values of your main router
before running anything.
- Thorough Reset — hold Reset for 30 seconds with the power on.
- Open the repeater's web interface and go to Tools → System Commands.
- Paste the
nvram set …line fromnvram-setup.shand run it. The router reboots by itself at the end. - Go to Administration → Scripts → Init, paste the contents of
init-script.sh, and save. - Reboot once more.
- Verify with
diagnostics.sh. In particular,wl -i wl0.1 apmust return1andbrctl show br0must listeth1,vlan0andwl0.1.
Administration → Buttons/LED has no LED switches on this model — BCM53572 does not
expose them there. The button GPIOs (rescue_gpio=22, reset_gpio=23) are not LEDs.
The working pins were found by brute force: gpio disable N; gpio enable N across every
pin from 0 to 21, skipping 22 and 23 because those are the buttons.
- GPIO 5 and GPIO 18 drive the activity LEDs.
- Permanent, with a one-minute delay after boot: the last lines of
init-script.sh. - Immediately, without a reboot:
gpio disable 5; gpio disable 18 - To restore:
gpio enable 5; gpio enable 18
When the password on the main router changes, the repeater loses its association. Both sides — the WET client and the virtual AP — have to be updated together.
From Tools → System Commands on the repeater:
nvram set wl0_wpa_psk="NEW_PASSWORD"; nvram set wl0.1_wpa_psk="NEW_PASSWORD"; nvram commit; sleep 2; rebootOrder of operations matters:
- Open the repeater's interface and prepare the command with the new password, but do not run it yet.
- Change the password on the main router.
- Run the prepared command immediately — the repeater still holds its old association.
- After the reboot it comes back up with the new password.
If you are too late and the repeater has already dropped off, connect to it with an Ethernet cable and do the same through its LAN address.
The same approach, with wl0_ssid and wl0.1_ssid. To change both SSID and password:
nvram set wl0_ssid="NEW_SSID"; nvram set wl0.1_ssid="NEW_SSID"; nvram set wl0_wpa_psk="NEW_PASSWORD"; nvram set wl0.1_wpa_psk="NEW_PASSWORD"; nvram commit; sleep 2; rebootRemember to update the SSID in the Init script as well
(wl -i wl0.1 ssid "NEW_SSID"), otherwise the virtual AP comes back on the old name.
If the 2.4 GHz channel changes on the main router, match it on the repeater:
nvram set wl0_channel=CHANNEL_NUMBER; nvram commit; service wireless restartBack up through Administration → Configuration → Backup (a .cfg file).
Warning: that file contains the Wi-Fi PSK in cleartext. Keep it out of version control —
*.cfgis already in.gitignore.
Restoring an old backup onto a running system is not recommended. A full Thorough Reset
followed by nvram-setup.sh and the Init script is more reliable. In my experience old
backups carry artefacts of intermediate experiments — a stale wan_proto=dhcp, for
example — and the resulting problems only surface a day later.
MIT — see LICENSE.