Bug Description
1. Summary
Fire TV Stick HD (2026, Vega OS 1.2, build 48) runs its Wi-Fi in a power-save mode in which it does not receive broadcast frames for 30+ seconds at a time, and after sleep/reboot it becomes unreachable from the LAN altogether, while Settings > Network keeps showing “Connected, strong signal” with a valid IPv4. Measured from a Mac on the same 2.4 GHz WPA2 network:
- Unicast to the device (ICMP with a cached ARP entry) is not lost but delivered in bursts: the device wakes only every 2 to 8 seconds, and all frames the AP buffered arrive at once (ping RTTs of 8054, 7052, 6047 … 1026, 21 ms in one burst, 0% loss).
- Broadcast reaches the device only in short windows more than 30 s apart: sending our UDP discovery broadcast once per second, the first 34 probes got no reply, then the device answered for the rest of the 90 s. A host that deletes its ARP entry for the device (
arp -d) cannot resolve it again for 20-60 s (ARP requests are broadcast) and sees “Host is down”; the entry only comes back when the device itself sends something to that host (then the device’s own ARP request fills the host’s cache). Any sender app that searches for a few seconds never finds the device. - After sleep or reboot the device is unreachable outright (100% loss, ARP incomplete, for many minutes) until the network is forgotten and re-joined.
- Device-initiated traffic keeps working throughout (Prime Video streams, the speed test runs), so the user sees nothing wrong.
- Only forgetting the Wi-Fi network and re-joining with the password recovers the post-sleep state reliably. Device activity (speed test, opening network details, playback) recovers it only sometimes.
This breaks every app that must be reached from the LAN (casting, mirroring, remote control, local media). Amazon Appstore review reported “Displays could not connect to the device” for our app on the two Vega devices only (all 95 Fire OS devices passed); Developer Support (case 21994709151) confirmed the app itself is fine and pointed to the device side, so we are filing it here. Our app was not even running during the measurements below, so this is independent of the app.
App Name: MirrorBeam (package jp.jx83.mirrorbeam)
App Link on Amazon Appstore (found through Developer Console → Actions column in App List → View on Amazon.com): MirrorBeam - Screen Mirroring - App on Amazon Appstore
Bug Severity
Select one that applies
- Impacts operation of app
- Blocks current development
- Improvement suggestion
- Issue with documentation (If selected, please share the doc link and describe the issue)
- Other
2. Steps to Reproduce
- Connect the Fire TV Stick HD to a 2.4 GHz WPA2 home Wi-Fi. Confirm Settings > Network shows “Connected” and an IPv4 address.
- From Mac A on the same Wi-Fi, run
ping -i 2 <device IP>and leave it running with timestamps. Right after joining it answers in a few ms. - Put the remote down and do not touch the device (home screen or any app; our app was not running). After about 3 minutes the Prime Video promo takes the screen, after about 4 minutes the screensaver starts. Do nothing else.
- Watch Mac A: RTT rises to 1 to 8 seconds, replies arrive in bursts, timeouts per minute grow (0 → 4 → 12 per 30 pings). About 10 minutes after the last input the replies stop completely and
arp -n <device IP>shows(incomplete); ping reports “Host is down”. - As root, delete the ARP entry and ping:
arp -d <device IP>; ping -c 15 <device IP>; arp -n <device IP>→ 100% loss, “No route to host / Host is down”, entry stays(incomplete)for the whole 15 s (repeated three times, also while the device answered unicast pings in 2-4 ms seconds earlier). The device does not receive the broadcast ARP requests. The entry reappears only 20-60 s later, and only because the device sends its own ARP probe when it answers something (verified: with no traffic from the Mac at all, the entry stayed incomplete for 20 s and was filled within 15 s of a device-initiated ping).
5b. Send the UDP discovery broadcast once per second for 90 s: no reply for the first 34 s, then replies to most probes. So broadcast is delivered only when the device wakes for it, roughly every 30 s or more. - Settings > Network > forget the network, re-enter the password: ping/ARP answer immediately from both Macs and the app (when running) is discoverable and reachable again.
- Alternatively: put the device to sleep or reboot it. After it comes back, Settings shows Connected but step 5 fails immediately (recorded on video).
Observed over 4 days on two different networks (192.168.110.0/24 and 192.168.111.0/24, both 2.4 GHz WPA2, different routers). No specific React Native call is involved; the app does not need to run.
3. Observed Behavior
Timeline (2026-09-24, JST, device idle, our app NOT running, Mac A pinging every 2 s):
04:09 last remote input; ping answers, but already avg 1.6 s RTT, max 3.7 s
04:11:45 Prime Video promo takes the screen
04:12:45 screensaver starts (no change in ping behaviour at that moment)
04:14 27 replies / 4 timeouts per minute, avg 1.7 s, max 5.4 s
04:17 25 replies / 7 timeouts, max 5.3 s
04:18 16 replies / 12 timeouts, max 6.9 s; first 28 s window with no reply at all
04:19 8 replies / 5 timeouts, avg 2.8 s, max 7.9 s
04:22:03 ARP entry deleted on the Mac for the test in step 5 -> "Host is down" for 60 s
04:23:02 entry back (device's own ARP probe), RTT 3 ms to 1.5 s for ~3 minutes, then decay
04:26:56 28 s without any reply; a few minutes later the screen went black (sleep). After
sleep it stays unreachable until the network is forgotten and re-joined.
04:31 network forgotten and re-joined; reachable again (RTT 4-250 ms)
04:32-04:50 device-side ping loop (1/s to the gateway): 0 timeouts, avg 60-250 ms
04:54-05:40 our app (build 37, 1 UDP packet/s) on the waiting screen: 0-1 timeouts, avg 30-230 ms
05:44-06:30 app terminated by the OS (display off), no app traffic: still 0 timeouts,
avg 90-240 ms, and the same overnight (06:30-11:28: 8874 replies, 43 timeouts).
So unicast to a host with a cached ARP entry stays fine; what never recovers
without a re-join is the post-sleep state, and what is always slow is broadcast.
(device showed Connected, strong signal, valid IPv4 the whole time)
Burst pattern on Mac B (default ping, cached ARP entry), same period:
Request timeout for icmp_seq 0 ... 7
64 bytes: icmp_seq=0 time=8054.939 ms
64 bytes: icmp_seq=1 time=7052.418 ms
64 bytes: icmp_seq=2 time=6047.398 ms
...
64 bytes: icmp_seq=7 time=1026.139 ms
64 bytes: icmp_seq=8 time=21.924 ms
64 bytes: icmp_seq=9 time=4179.584 ms <- next burst, device slept ~4 s
...
31 packets transmitted, 31 received, 0.0% loss, rtt min/avg/max = 2.9/2465.9/8054.9 ms
=> nothing is lost; the AP buffers the frames and the device wakes every 2 to 8 s.
ARP test (root) on the same Mac that was pinging with a cached entry (the cache was deleted here):
# arp -d 192.168.111.48; ping -c 15 192.168.111.48; arp -n 192.168.111.48
Request timeout for icmp_seq 0..3
ping: sendto: No route to host
ping: sendto: Host is down (repeated)
15 packets transmitted, 0 packets received, 100.0% packet loss
? (192.168.111.48) at (incomplete) on en0 ifscope [ethernet]
=> ARP requests (broadcast) are not received; only hosts with a cached MAC can reach it.
The entry came back 60 s later (first test) / 23 s later (second test), each time
right after the device itself sent an ARP probe toward the Mac.
Broadcast discovery probe (our "MBDISCOVER v1" to 255.255.255.255:53515) once per second
for 90 s, app running on the device, ARP cached:
no reply for probes 1..34, then replies at 34.3 s, 37.3 s, 40.5 s ... (most probes answered
from then on, some delivered in bursts: three replies at 59.2 s)
=> the device does not receive broadcasts for 30+ s, then receives them for a while.
Pinging 5 times per second for 30 s lowers the RTT (avg 1.0 s -> 0.3 s) but does not
bring it back to a few ms; inbound traffic alone does not wake the device up.
Outbound-initiated traffic keeps working the whole time: Prime Video plays, the speed
test reports normal speeds. Recovery is inconsistent: sometimes the device starts
answering after such activity, sometimes it stays unreachable while a video streams.
Only Settings > Network > forget + re-enter password recovers it every time; right after
that, ping RTT is 3 ms and ARP resolves at once.
Same behaviour with our app in the foreground, in the background, and not running.
Fire OS sticks on the same routers answer ping in a few ms indefinitely and always
answer ARP.
4. Expected Behavior
While Settings shows "Connected", the device should answer ARP/ICMP from its subnet and
inbound UDP/TCP should reach a listening app, exactly as it does right after joining.
If the Wi-Fi stack has actually lost inbound connectivity, the UI should say so or the
stack should reconnect automatically, instead of showing "Connected" indefinitely.
4.a Possible Root Cause & Temporary Workaround
Root cause (from the measurements): Wi-Fi power save on this device is far too aggressive.
After a few minutes without input the station sleeps for 2 to 8 seconds at a time (the
listen interval keeps growing), so unicast is delivered late in bursts, and it evidently
skips DTIM beacons, so broadcast/multicast (ARP requests, service discovery, mDNS/SSDP)
is never received. Once the other hosts' ARP caches expire the device is unreachable.
It looks like the Wi-Fi firmware's power-save/DTIM-skip parameters for the "idle" state
are wrong (or ARP offload is not configured), and only a re-association resets them.
This is a device/OS issue; there is no app API that could influence it (see also the
open feature request for a keep-screen-awake API:
https://community.amazondeveloper.com/t/28610 ).
Workaround (user): Settings > Network > forget the Wi-Fi network, then reconnect with the
password. Restores connectivity immediately and reliably. Speed test / network details /
video playback restore it only sometimes.
Workaround (app): device-initiated traffic brought a degrading device back and kept it
reachable: (1) a shell loop on the device pinging the gateway once per second: 13 minutes
idle, 0 timeouts, avg 60-250 ms; (2) our receiver app sending a small UDP packet once per
second (broadcast + default gateway): 50 minutes idle on the waiting screen, 1 timeout,
avg 30-230 ms, ARP answered, discovery and TCP work. Caveat: after that, with the app
terminated and no app traffic at all, the same association stayed reachable for another
50 minutes (0 timeouts, avg 90-240 ms), so "no traffic from the device" alone does not
explain when the deep state is entered; the reliable triggers we have seen are sleep,
reboot, and the first minutes after re-joining a network (recorded on video). We are
shipping the periodic packet in our receiver as a mitigation, but it cannot help while
the app is not running or the device sleeps, so the OS should fix the power-save
behaviour.
5. Logs or crash report
No crash. The app does not crash and prints no error, because from its point of view nothing arrives. Device-side logs are hard to collect in the affected state: vega exec vda connect <ip>:5555 over Wi-Fi also fails (same cause). We can capture a vega device doctor bundle over USB the next time it reproduces and attach it here. Please tell us which additional logs (Wi-Fi driver / connectivity service) would help and how to enable them.
6. Environment
-
SDK Version: Active SDK Version 0.24.9914 / Vega CLI Version 1.3.4
-
React Native Version: RN0.83 (react-native 0.83.0, @amazon-devices/react-native-kepler ~4.0.0)
-
App State: Not running during the measurements above. Also reproduces with the app in Foreground (idle screen) and in Background; it is a device state, not an app state.
-
OS Information: Fire TV Stick HD (2026), serial A3I4VPCZR2XR3U
NAME="OS" OE_VERSION="4.0.0" OS_MAJOR_VERSION="1" OS_MINOR_VERSION="2" RELEASE_ID="23" OS_VERSION="1.2" BRANCH_CODE="TV Ship" BUILD_DESC="OS 1.2 (TV Ship/48)" BUILD_FINGERPRINT="4.0.327075.0(af87c227d5854e74)/48N:user/release-keys" BUILD_VARIANT="user" BUILD_TAGS="release-keys" BUILD_DATE="Thu Sep 10 22:27:20 UTC 2026" BUILD_TIMESTAMP="1789079240" VERSION_NUMBER="2301020004820"
7. Example Code Snippet / Screenshots / Screengrabs
No React Native component is involved. The listener is a C++ TurboModule using standard BSD sockets:
// receiver-module (C++ TurboModule), simplified
int u = socket(AF_INET, SOCK_DGRAM, 0); // bind(0.0.0.0:53515) -> OK, recvfrom() never returns in the affected state
int t = socket(AF_INET, SOCK_STREAM, 0); // bind(0.0.0.0:53516) + listen() -> OK, accept() never returns in the affected state
Both sockets keep working after the network is forgotten and re-joined, without restarting the app.
Playback Issues
N/A (not a playback issue)
- Player SDK: N/A
- Player SDK Version: N/A
- Audio Codecs: N/A
- Video Codecs: N/A
- Manifest Types: N/A
Q: If applicable, please provide your media/content url
N/A
Q: Are there any special headers required to reproduce the issue you are facing?
N/A
Additionally please provide the following if possible
Video 1 (review-side symptom and the workaround: ping fails, re-join Wi-Fi, connect works):
https://www.jx83.jp/mirrorbeam/vega.mp4
Video 2 (sleep / reboot -> ping stops answering; Prime Video still plays while unreachable;
speed test etc. recover it only sometimes; re-entering the Wi-Fi password recovers it every time):
https://www.jx83.jp/mirrorbeam/vega2.mp4
Additional Context
- Fire OS devices (Fire TV Stick 2nd/3rd gen) on the same routers: ping a few ms indefinitely, ARP
always answered. Only the Vega device shows this.
- Router settings were not changed between the tests; the same AP serves the Fire OS sticks.
- Appstore review of our 1.0.2/1.0.3 failed only on the two Vega devices (Fire TV Stick 4K Select,
Fire TV Stick HD 2nd gen) with "could not connect"; 95 Fire OS devices passed. The reviewer's
video showed no ping check, so we believe they hit this state.
- Developer Support case 21994709151: "the app itself is fine; possibly a Vega device-side problem".
- We are happy to run any diagnostic build or commands on the device and report back.