Diagnosing Amazon Device Wi-Fi Failures on ASUS Router (Merlin Firmware)
I ran into a persistent issue where my Amazon Echo Spot and Kindle refused to connect to my home Wi-Fi network, despite other devices working fine. The Echo would complete setup via my phone’s hotspot, but fail when switching to my router. The Kindle showed an “Application Error” even after entering the correct Wi-Fi credentials.
Both devices had worked previously, and my network is powered by an ASUS RT-AX86U Pro running Merlin firmware, with multiple access points and a well-tuned 2.4 GHz band.
Symptoms
- Echo Spot setup would hang on “Connecting…” and eventually fail.
- Kindle would show “Application Error” after attempting to join Wi-Fi.
- Both devices connected successfully to a phone hotspot.
- Router logs showed DHCPNAK errors for both devices:
DHCPREQUEST 192.168.1.250
DHCPNAK wrong server-ID
1. MAC Address Conflict
Initially suspected a duplicate MAC address (0C:DC:91:5B:B8:28) on the network. This can cause ARP table flapping and DHCP instability. However, after isolating devices, this was ruled out.
2. Wireless Compatibility
Confirmed router was set to:
- Wireless Mode: Legacy
- Channel Bandwidth: 20 MHz
- Control Channel: 11
- WPA2-Personal with AES
- PMF: Disabled
These are ideal settings for legacy Amazon devices.
3. DHCP Behavior
Syslog revealed both devices were:
- Successfully associating with Wi-Fi
- Completing WPA2 handshake
- Then requesting a stale IP address from a previous session
- Router correctly rejected the request with a DHCPNAK
This confirmed the issue was device-side IP caching, not a router fault.
For Echo Spot:
- Factory reset the device (mute + volume down for 15 seconds)
- Completed setup via phone hotspot
- Switched to home Wi-Fi via Alexa app
- Assigned static IP via DHCP reservation on router
For Kindle:
- Forgot network and rejoined
- Assigned static IP via DHCP reservation
- Flushed DHCP leases on router
- Disabled VPN and IPv6 temporarily
- Set DNS to Google (8.8.8.8 / 8.8.4.4)
After these steps, both devices connected reliably and retained their IPs across reboots.
Lessons Learned
- Amazon devices may cache IPs aggressively and fail DHCP negotiation if the router doesn’t honor stale requests.
- Merlin firmware logs are invaluable for tracing DHCP behavior.
- Factory resets aren’t always necessary — DHCP reservations and lease flushes can resolve most issues.
- VPN routing and DNS can silently block device registration or service handshakes.
Final Recommendations
- Use Legacy mode + 20 MHz bandwidth on 2.4 GHz for IoT compatibility
- Assign static IPs via DHCP reservation for sensitive devices
- Flush DHCP leases after major network changes
- Monitor logs for
DHCPNAKanddisassociationevents - Disable VPN and IPv6 during device setup
Resolution Steps
For Echo Spot:
- Factory reset the device (mute + volume down for 15 seconds)
- Completed setup via phone hotspot
- Switched to home Wi-Fi via Alexa app
- Assigned static IP via DHCP reservation on router
For Kindle:
- Forgot network and rejoined
- Assigned static IP via DHCP reservation
- Flushed DHCP leases on router
- Disabled VPN and IPv6 temporarily
- Set DNS to Google (8.8.8.8 / 8.8.4.4)
Change the Wifi Settings on the router.
The Echo Spot doesn’t handle PMF negotiation on the router’s modern firmware, and disabling PMF removed the security feature it didn’t understand.
Disabling Protected Management Frames (PMF) on 2.4 GHz
Everything else I tweaked helped, but PMF was the real blocker.
Why PMF breaks older Echo devices
The Echo Spot was released in 2017, long before PMF became standard.
Its Wi‑Fi chipset:
- doesn’t support PMF
- doesn’t understand PMF negotiation
- misinterprets PMF‑capable beacons
- fails DHCP after association when PMF is present
- sometimes requests an IP from a “ghost” DHCP server because the handshake timing gets thrown off
When PMF is set to Capable, your router still advertises:
- PMF support
- PMF negotiation options
- IGTK (integrity group key) capabilities
- stricter key‑exchange timing
The Echo Spot sees this and basically goes:
“I don’t know what this is, but I’m going to panic and drop the connection.”g to panic and drop the connection.”
After these steps, both devices connected reliably and retained their IPs across reboots.
Lessons Learned
- Amazon devices may cache IPs aggressively and fail DHCP negotiation if the router doesn’t honor stale requests.
- Merlin firmware logs are invaluable for tracing DHCP behavior.
- Factory resets aren’t always necessary — DHCP reservations and lease flushes can resolve most issues.
- VPN routing and DNS can silently block device registration or service handshakes.
🛡️ Final Recommendations
- Use Legacy mode + 20 MHz bandwidth on 2.4 GHz for IoT compatibility
- Disabling Protected Management Frames (PMF) on 2.4 GHz
- Assign static IPs via DHCP reservation for sensitive devices
- Flush DHCP leases after major network changes
- Monitor logs for
DHCPNAKanddisassociationevents - Disable VPN and IPv6 during device setup