Issue Summary
Two Aqara G2H Pro cameras (HomeKit Secure Video) disconnect periodically with a consistent ~2h 10-19 min interval. Each outage lasts 2-9 minutes. The pattern is identical on both cameras but occurs at independent times, indicating an internal per-device timer rather than a network event.
Environment
- Router: ASUS RT-AX59U (FW 3.0.0.4.388_34011, MediaTek MT7986)
- Mesh nodes: 2× ASUS RT-AX55 (FW 3.0.0.4.386_53327), ethernet backhaul
- Cameras connected to: 2.4 GHz only, single active 2.4 GHz node (other node and router 2.4 GHz radio disabled) - excellent signal for cams
- Home Hub: Apple HomePod mini
- HomeKit Secure Video: enabled, iCloud storage only (no Aqara cloud storage)
- Signal strength: RSSI -28 dBm (cam1) / -36 dBm (cam2) per ASUS app; -38 / -48 dBm per Aqara app — excellent on both
- WiFi channel: fixed, non-DFS, 20 MHz bandwidth on 2.4 GHz
- WiFi password: alphanumeric only (special characters removed during troubleshooting)
Dominant interval: 2h 10-25 min. Occasional “double-tap” failures where a second shorter outage follows within 20 min of the first.
Key Observations
- Both cameras exhibit the same interval independently — different absolute times, same periodicity.
- During outages the camera remains associated to the WiFi AP (shown as connected in ASUS router/node client list) but becomes unreachable in Aqara app and Apple Home app.
- No DE-AUTH, disassociation, or any WiFi-layer event is logged on the router during camera outages.
- Signal strength is excellent and stable throughout.
- The pattern persists identically across all configuration changes listed below pointing to camera failures.
Troubleshooting Performed (router side, exhaustive)
All of the following were tested individually and in combination. None changed the disconnect pattern:
Network rebuilds:
- 3× full factory reset of router + both mesh nodes
- Complete AiMesh re-provisioning with sequential node addition, several times
- Cold boot (full power cycle) of entire network including all IoT devices
WiFi settings (2.4 GHz):
- Fixed channel (non-DFS), 20 MHz bandwidth
- Multicast rate: OFDM 6
- Disable 802.11b
- Roaming Assistant: tested ON (-70 dBm) and OFF
- Smart Connect: tested ON and OFF
- IGMP Snooping: tested ON and OFF
- WMM APSD: tested ON and OFF
- MU-MIMO: tested ON and OFF
- Explicit Beamforming: tested ON and OFF
- Universal Beamforming: tested ON and OFF
- 256-QAM (TurboQAM): tested ON and OFF
- Xtra Range 2.0: tested ON and OFF
- Airtime Fairness: tested ON and OFF
- TX Power: tested Power Saving and Balance
- Preamble: Short
- Bind (device-to-node assignment): tested ON and OFF
- Roaming Block List: tested ON and OFF
- 2.4 GHz radio on main router: disabled (only one mesh node serves 2.4 GHz — eliminates multi-AP ambiguity)
Conclusion
The ~2h periodic disconnect is not caused by WiFi signal, channel, router settings, mesh topology, or network configuration. The pattern points to an internal timer within the G2H Pro firmware — possibly a cloud session refresh, HomeKit Secure Video session rotation, or watchdog timer that triggers a WiFi stack reset. The fact that WiFi association remains intact during the outage while application-layer connectivity is lost supports this interpretation.
Request
- Is there a known issue with periodic disconnects on G2H Pro firmware related to cloud keepalive, HKSV session rotation, or internal watchdog timers?
- Is there a beta firmware available that addresses this behavior?
- Are there any camera-side settings (not visible in the Aqara app) that control session refresh intervals?
Device Information
- Camera model: Aqara G2H Pro (CH-C01)
- Camera firmware: 4.5.30_0002.0013
4 Likes
Hi there, it looks like you’re experiencing a support-related issue. We’ve automatically created a support ticket for you and will reach out via the forum email within the next two business days.
If other members have any suggestions or insights on this topic, feel free to share!
1 Like
Following up on this - have you found any solution or received a response from support?
1 Like
Aqara identified an mDNS error in the device log. Router settings ‘Advertise router’s IP in addition to user-specified DNS’ in ASUS DHCP settings was enabled. I disabled it, but so far after 48h - no improvement at all.
Aqara also recommended enabling UPnP, but I am holding off on that due to security concerns.
Wait, so Aqara actually recommended you enable UPnP? Are you sure the support agent didn’t end the email with: “This is only for your convenience, my friend!”?
Seriously though, suggesting UPnP in this day and age as a “fix” is a massive security red flag. It feels like they are just throwing random network settings at the wall to see what sticks, rather than admitting the hardware is failing.
Since you’ve seen no improvement after 48h with the mDNS changes, it’s pretty clear the issue isn’t in your ASUS settings. Have they offered you anything else, or just more “convenient” ways to compromise your network?
1 Like
Look, since this only happens every couple of days, you’re going to lose your mind trying to tweak individual settings. Just swap the ASUS for literally any other router for a few days - borrow one or use an old ISP box.
Network bugs like this are a nightmare to debug, and if it’s an ASUS + Aqara combo glitch, it’s basically impossible to fix unless someone has that exact same hardware setup to reproduce it. If you can prove it only happens with this combo, you can actually tell Aqara to test it on that specific hardware. Otherwise, they’ll just keep staring at logs that tell them nothing and you’ll get nowhere.
This swap is the only way to get a real answer: if the problem disappears after a few days, it’s a compatibility issue with this specific combo. If it still drops, then the camera is just straight up junk. Better to run a different router for a week than to keep chasing ghosts in the settings for another month.
I have been doing some further research.
Both G2H Pro cameras disconnect with recurring offline events at ~2h 10-19 min intervals. Each outage lasts 8-9 minutes. Error code is either network-612 or no error code displayed (camera shows as offline without specific error). Pattern is identical on both units, independent timing per camera.
- Fixed non-DFS WiFi channels
- DNS configurations tested: Cloudflare 1.1.1.1, Google 8.8.8.8, ISP DNS, router IP as DNS
- “Advertise router’s IP as DNS”: disabled
- NAT conntrack table verified with SSH: max 300,000 entries, active count 167 — no pressure
- TCP conntrack timeout and keepalive extended via SSH
Key finding
During offline event, router conntrack table for camera IP shows zero external connections — camera makes no reconnect attempt to TUTK coordinators or Aqara backend during the entire outage period:
udp src=192.168.x.x dst=224.0.0.251 dport=5353 [UNREPLIED] ← mDNS only
unknown src=192.168.x.x dst=224.0.0.251 [UNREPLIED]
Conntrack during normal operation (immediately after camera self-recovered):
tcp ESTABLISHED src=192.168.x.x dst=43.157.55.49 dport=11121 [ASSURED] ← Aqara backend
tcp ESTABLISHED src=192.168.x.x dst=49.51.141.14 dport=32110 [ASSURED] ← TUTK
udp ASSURED src=192.168.x.x dst=49.51.141.14 dport=32100 ← TUTK P2P
udp src=192.168.50.1 dst=192.168.x.x sport=67 dport=68 ← DHCP renew after WiFi stack restart
Prior to and during outages, conntrack showed SYN_RECV burst on TCP connections from camera to 43.131.7.8:15050 and 49.51.x.x:32110 (10-30 simultaneous SYN_RECV entries per outage event), combined with high volume of UNREPLIED UDP toward TUTK coordinators on port 32100. Camera initiates mass connection attempts which do not complete, followed by complete loss of all external connections confirmed by SSH conntrack query during active outage. This sequence seems to be consistent across all observed outage events on both camera units.
The camera attempts to establish a connection with the servers (TUTK/Aqara), but for an unidentified reason, fails to complete the standard three-way handshake.
The [UNREPLIED] status on port 5353 (mDNS), combined with the total absence of TCP sessions directed at the Aqara backend, indicates that the camera’s primary communication process has either entered a hang state or crashed, leaving only the local discovery service operational.
The accumulation of SYN_RECV entries likely leads to the exhaustion of the camera’s internal socket memory. During outage the camera loses all external connections and enters mDNS-only loop. It does not attempt to reconnect to TUTK or Aqara servers. Recovery occurs only after assumed internal watchdog restarts the WiFi stack (~8-9 min), as confirmed by the subsequent DHCP renew event. UPnP confirmed irrelevant — conntrack shows camera operates via symmetric NAT relay to TUTK servers, no direct P2P port mapping required or used. This behavior is reproducible on both units across several network configurations tested. Router-side parameters seems to have no effect.
This appears to be a firmware-level bug in the cloud reconnection logic of G2H Pro.
2 Likes
Just wanted to say this is an elite-level analysis. Have you shared these findings (especially the SYN_RECV burst and socket exhaustion part) with Aqara support or their dev team? It seems like a 100% reproducible firmware bug that they shouldn’t be able to ignore.
Yes I did. I received information today = “It appears there is an issue with the device’s Wi-Fi hardware.” and they provided warranty service.
I need to challenge the Wi-Fi hardware diagnosis, as the router log data directly contradicts it.
What the router conntrack log does show, consistently across 18 captured disconnect events over two days. mDNS and IGMP multicast traffic from the camera continues uninterrupted. There is no Wi-Fi-layer disconnect.
The pattern of failure mode is identical on both cameras independently, which is not consistent with a hardware defect.
Both cameras (G2H Pro) monitored continuously via cron job on the ASUS RT-AX59U router running cat /proc/net/nf_conntrack | grep <camera_IP> every 30s/60s.
I have way over 20k log records of all connections past 2 days. Well to ease the job, I have used some AI tools to do the analysis of the logs. Each event was correlated with the offline/online status displayed in the Aqara Home app.
This is the output:
Pattern definitions
Pattern A — Extended outage (8-14 min) with SYN flood to 43.131.7.8:15050
- Camera enters reconnect state
- Camera initiates TCP SYN to 43.131.7.8 on port 15050 (Aqara cloud endpoint)
- Server does NOT respond — connection stays in SYN_RECV state in conntrack until kernel timeout
- Camera retries 50-240 times during the outage window before giving up
- Eventually camera attempts a different cloud server (43.131.46.8:11121, 43.131.26.232:11121, etc.) and reconnects
Pattern B — Short outage (2-3 min) with clean reconnect
- TCP connection on port 11121 to one of 43.157.7.2 / 43.157.31.62 / 43.157.55.49 / 43.131.34.158 / 162.62.219.201 enters LAST_ACK state
- Camera reconnects to the same or adjacent cloud server within 2-3 minutes
- No SYN attempts to 43.131.7.8 are observed
- Outage is brief and self-healing
Statistics
- Total events captured: 18
- Pattern A (extended outage): 11 events (61%)
- Pattern B (short outage): 7 events (39%)
- Pattern A average duration: 8.5 min
- Pattern B average duration: 2.9 min
- Pattern A SYN flood total to 43.131.7.8:15050: 1837 failed attempts across 11 events
- Cloud servers seen as pre-outage active connection: {‘43.131.46.8’: 6, ‘43.157.31.62’: 3, ‘43.157.55.49’: 2, ‘43.157.7.2’: 3, ‘162.62.219.201’: 1, ‘43.131.26.232’: 1, ‘43.131.34.158’: 1}
- Cloud servers seen as post-outage reconnect target: {‘162.62.219.201’: 2, ‘43.157.31.62’: 3, ‘43.131.46.8’: 6, ‘43.157.55.49’: 2, ‘43.157.7.2’: 1, ‘43.131.26.232’: 1, ‘43.131.34.158’: 2}
Repeating failure mode (summary)
Failure mode 1 (Pattern A — primary cause of long outages):
- Camera attempts to establish TCP connection to 43.131.7.8 on port 15050
- The server at 43.131.7.8:15050 does not respond to SYN packets
- Camera retries this same destination repeatedly during the outage
- Each failed attempt consumes ~30 seconds (TCP SYN retry timeout)
- Outage duration scales linearly with retry attempts (8-14 min per outage = 16-28 retries)
- Consequence: camera is offline in Aqara app and Apple Home app for the full retry duration
Failure mode 2 (Pattern B — short cyclic disconnect):
- Existing TCP keepalive connection on port 11121 enters LAST_ACK state
- This indicates one side has sent FIN; bidirectional FIN exchange completes
- Camera reconnects to the same or another cloud server within ~3 minutes
- Consequence: brief outage but recovery is automatic
Common consequence: camera unavailable in Aqara Home and Apple HomeKit (HomeKit Secure Video stream interrupted) for the full duration of the disconnect window. No HSV recording during outage.
Key observations
- 43.131.7.8:15050 unresponsiveness — Is this endpoint expected to respond? It is repeatedly used as the camera’s first reconnect target but never replies during any of the 11 Pattern A events captured. If this is a deprecated server, the camera firmware should have been updated to remove it from the reconnect priority list.
- Cloud server pool fragmentation — The camera connects to one of at least 7 different cloud server IPs (43.157.7.2, 43.157.31.62, 43.157.55.49, 43.131.46.8, 43.131.34.158, 43.131.26.232, 162.62.219.201) on TCP port 11121. After a disconnect, the reconnect logic seems to prefer 43.131.7.8:15050 first instead of returning to the previously working cloud server.
- Disconnect frequency — Captured cadence is 1-3 hours between events per camera, identical pattern on both cameras.
- DNS hypothesis is excluded — Earlier troubleshooting per Aqara support recommendation set ‘Advertise router’s IP as DNS: NO’. Router NVRAM dump confirms DHCP distributes ISP DNS to clients, not the router IP. Disconnect pattern is unchanged after this fix. The DNS queries to <router_ip> visible in conntrack appear only during the reconnect phase as a side effect, not as a cause.