[PR Submitted] Fix for frequent WWAN (LTE/5G) disconnects & Request to sync public GitHub repo

Hello Photonicat team and community!

I've recently been investigating an issue where the WWAN (LTE/5G) interface and associated tunnels (OpenVPN/WireGuard) drop unexpectedly. I've found the root cause in the pcat-manager daemon and submitted a Pull Request with a fix.

The Problem:

1. Transient WAN Flaps: OpenWRT's eth-powersave script (or a standard DHCP renewal) causes a momentary flap on the wired wan interface. The mwan thread reacts instantly and tears down the WWAN interface without any hysteresis.
2. Stale Configuration: Disabling "Auto Stop WWAN if Wired" in the Web UI doesn't apply at runtime because the daemon caches the old value until a restart.

The Solution:
I have submitted a PR here: github

The fix introduces two key changes:

• Debounce Logic (src/main.c): Added a 3-strike debounce mechanism (approx. 9 seconds). The daemon now requires the WAN interface to remain in a changed state for multiple polling cycles before transitioning the WWAN state. This successfully filters out transient hardware/network flaps.
• Runtime Sync (src/controller.c): Added the missing pcat_main_network_modem_iface_auto_stop_set() call so the daemon immediately respects the Web UI configuration.

⚠️ Important Note on Public Repository Sync

While compiling and testing this fix locally, I noticed a significant issue with the public repository: The public master branch is severely outdated compared to the production firmware.

When running the daemon compiled from the latest public commit (June 8, 2026) alongside the current Web UI, the UI breaks and throws several errors:

• Not supported by this MCU firmware (Requires MCU firmware RA2E1260715004 or newer) in the Battery section.
• Missing battery center-tap sensing data.
• Errors regarding missing endpoints like soc-log-get and modem logs.

The hardware (MCU) is up-to-date, but the public C-backend is missing all the recent features that the new Web UI expects. It seems the backend code was updated for the latest OTA releases but never pushed to the Open Source repository.

Could the maintainers please sync the public pcat-manager repository with the internal production branch?

This would allow the community to properly compile, test, and contribute patches (like the WWAN debounce fix) without breaking the Web UI diagnostics.

Thanks for your hard work on this great device! Looking forward to your feedback on the PR.

Update: USB 3.1 (5Gbps) is stable in my setup. Sharing findings on a DNS race condition.

I wanted to share a quick update based on my specific case. I've been running the modem on USB 3.1 5Gbps with zero drops (even while moving and switching cell towers). I am not sure if this applies to everyone experiencing USB 3.0 instability, but for my device, the issue was actually tied to a software/DNS race condition rather than a strict hardware limitation.

Since I don't use a wired wan connection, the cellular wwan is my only source of upstream DNS servers. Here is exactly what was happening on my end during a hardware micro-flap (like a tower handover or a slight USB bus delay):

1. The DNS Flush: The moment the wwan link flaps, OpenWRT's netifd immediately purges the dynamically assigned ISP DNS servers from dnsmasq.
2. The Watchdog Panic: Without any upstream DNS servers available, any network check performed by pcat-manager fails instantly (local resolver error) rather than timing out gracefully. The daemon interprets this instant failure as a dead link and aggressively restarts the modem.

My Workaround:
I manually added a static upstream DNS (1.1.1.1) in the dnsmasq forwarders (Network -> DHCP and DNS -> Forwards).
Because dnsmasq now has a permanent static route, it doesn't clear its resolver list during a transient interface drop. The daemon's network checks simply hang for a few seconds instead of failing instantly. This natural DNS timeout acts as a buffer, giving the wwan interface the exact time it needs to recover on its own.

Combined with the debounce PR I submitted (src/main.c), my RM520N modem is now rock-solid on full USB 3.1 speeds.

Hopefully, this workaround helps others who are currently forced to use USB 2.0. It might be worth checking if your disconnects are also triggered by this DNS/watchdog behavior!

Hi,
Manually merged your pull request on Github, since there are some conflicts with the codes we changed recently.

Awesome, I saw that the code was manually merged into the master branch! 🎉

A huge thank you to the team for taking the time to review the PR and for syncing the public repository with the latest backend commits. It's great to have the open-source repo fully up-to-date with the current Web UI and MCU features.

Really appreciate your hard work and responsiveness!