Critical: NR7302 Cell Lockout & eth0 Drops — Disrupting Greenhouse Remote Monitoring

Hi,

your problem seems similar to mine.

Check out the solution I've already posted in this other community post:

Hi,

I am experiencing what appears to be the same issue with an NR7302 running Telekom DE firmware 1.00(ACHA.5)b1_F0.

My original topology was:

NR7302 in router/NAT mode
  → Ethernet
  → TP-Link Deco X50 in Access Point mode
  → wired and Wi-Fi clients

Symptoms

After several hours, individual clients lost Internet access, especially Xiaomi/Honor phones and some Wi-Fi cameras. Wired clients were affected much less frequently and not necessarily at the same time.

During the failure:

• local access to both the NR7302 and Deco management interfaces continued to work;
• Internet ping still worked;
• the NR7302 diagnostic ping, traceroute and nslookup all worked;
• DNS changes did not solve the problem;
• HTTP/HTTPS and applications on affected clients timed out;
• http://1.1.1.1 returned the redirect to Cloudflare, but the subsequent HTTPS connection timed out with ERR_TIMED_OUT;
• disabling/re-enabling Wi-Fi or airplane mode on the phone did not restore connectivity.

A wired PC was able to maintain a three-hour online call while some Wi-Fi devices could not open websites. This suggests that the cellular WAN itself was still operational and that the failure was selective per client or per flow.

Tests that did not solve it

I tested:

• two different mobile operators: WindTre and ho. Mobile;
• IPv4-only PDP;
• LTE-only mode;
• manual Cloudflare DNS;
• Fast Roaming and Beamforming disabled on the Deco;
• a different Ethernet cable;
• the NR7302 “Post Routing” feature.

None of these prevented the issue.

The connection could be restored by:

• applying almost any network-related setting on the NR7302;
• rebooting the Deco;
• or simply disconnecting and reconnecting the Ethernet link between the NR7302 and the main Deco.

The last observation may point to stale bridge/FDB, conntrack or hardware-offload state rather than a cellular disconnection.

Preliminary workaround: IP Passthrough

I have now changed the topology to:

NR7302: IPv4 IP Passthrough
  → Deco X50 in Router mode
  → NAT and DHCP handled by the Deco

NR7302 settings:

PDP type: IPv4
IP Passthrough: Enabled
Passthrough mode: Dynamic
Static Gateway: Disabled
Subnet Prefix: 0
DHCP Lease Time: 0
Proxy ARP: Disabled
VLAN Offload: Disabled
Post Routing: Disabled

Deco settings:

Operating mode: Router
WAN connection: Dynamic IP
WAN Unicast: Enabled
LAN: 192.168.68.0/22

The Deco now receives the carrier CGNAT address directly (100.64.0.0/10 range), rather than a 192.168.1.x address, confirming that IP Passthrough is active.

So far this configuration has remained stable for several hours and successfully passed the first full night, which normally did not happen in my previous router/AP configuration.

This is not yet proof of a permanent fix. I will continue testing for at least 5–7 days and post another update. However, the initial result suggests that moving per-client NAT/DHCP from the NR7302 to the downstream router may avoid the faulty state.

It would be useful if other affected users could test the same configuration and report whether IP Passthrough with a downstream router also improves stability.