TRB501 - Bridge/Passthrough Mode Broken + Modem Crashes on T-Mobile 5G SA (FW 7.19.4 → 7.21)

Networking Solutions
1

Device Info

  • Device: TRB501
  • RutOS: TRB501_R_00.07.19.4 (tested), upgraded to TRB501_R_00.07.21 (tested)
  • Modem FW: RG520NEBDCR03A01M4G
  • Kernel: 5.4.197-perf
  • Carrier: T-Mobile US (MCC 310, MNC 260), 5G SA (E-NR-5GCN)
  • APN: fast.t-mobile.com (ipv4v6)
  • LAN Client: Mac Mini (d0:11:e5:25:cd:91) connected via 2.5GbE

Summary

I’m seeing three compounding issues that make bridge and passthrough modes completely unusable on T-Mobile 5G SA. NAT mode works fine, confirming the cellular data path is healthy. These issues have been tested and reproduced systematically across both firmware 7.19.4 and 7.21, with clean reboots between each mode change.

Issue 1: Modem Baseband Crash (RG520NE Firmware)

The Quectel RG520NE modem experiences fatal kernel exceptions that trigger Subsystem Restart (SSR). I’ve observed two distinct crash signatures across multiple occurrences:

Crash signature A (from passthrough mode):

subsys-pil-tz: subsys_err_fatal_intr_handler(): Fatal error on modem!
subsys-pil-tz: log_failure_reason(): modem subsystem failure reason:
  EX:kernel:0x1:diag:0x199:PC=0xc0c8c4e4:LR=0xc0c8c404:BADVA=0xfffff5c9:CAUSE=0x7003:SSR=0x1ff0070.

Crash signature B (observed on both 7.19.4 and 7.21, in both bridge and passthrough):

subsys-pil-tz: subsys_err_fatal_intr_handler(): Fatal error on modem!
subsys-pil-tz: log_failure_reason(): modem subsystem failure reason:
  dsm_queue.c:1622:WM 0xe2a4f458 current_cnt is not 0 .

The crash triggers Quectel_ModemFatalErrProcess and a full SSR cycle. The modem firmware reload takes ~12 seconds, followed by ~48 seconds for QTI reconnection, totaling roughly 60 seconds of complete connectivity loss. During recovery, the IPA WAN driver deinitializes and reinitializes (rmnet_ipa started deinitialization → rmnet_ipa completed initialization).

These crashes happen seemingly at random — I’ve seen them occur within 5 minutes of a fresh connection being established, and during steady-state operation.

I see this was reported in TRB501 - Intermittent loss of internet due to modem crashes and TRB500 - Modem crashing constantly. Is there an updated RG520NE modem firmware available that addresses these crashes?

Issue 2: eth0 Link Bounce on Every Mobile Interface Setup

Every time the mobile interface is brought up or reconfigured — mode change, SSR recovery, or any netifd reload — the r8125 2.5GbE NIC drops link and reinitializes. This takes br-lan down with it, killing all LAN connectivity for ~6 seconds.

The sequence is always:

r8125: eth0: link down
br-lan: port 1(eth0) entered disabled state
r8125_ioss: ioss:cfg:(eth0) Unmapped RX-1 event ...
r8125_ioss: ioss:cfg:(eth0) Unmapped TX-1 event ...
Switch Events: Port link state of port LAN1 changed to DOWN
...
eth0: 0xbf0d0000, 20:97:27:1b:c0:ea, IRQ 79    <-- NIC reinit
...
r8125: eth0: link up
br-lan: port 1(eth0) entered forwarding state
r8125_ioss: ioss:cfg:(eth0) Voted for IPA bandwidth of 2500 Mbps
r8125_ioss: ioss:cfg:(eth0) Mapped RX-1 event ...

On 7.19.4, the logs also showed Unknown attribute 'soft_reset' — netifd was attempting a soft reset that the r8125 driver doesn’t support, falling back to a hard link reset. The 7.21 netifd update removed that error message, but the eth0 link bounce still occurs on every mobile interface change.

This happens in all three modes (NAT, bridge, passthrough). In NAT mode it’s a brief blip. In bridge/passthrough it’s catastrophic because it triggers DHCP renegotiation with the WAN IP, creating a cascading failure (see Issue 3).

Issue 3: Bridge/Passthrough DHCP and Routing Completely Broken

This is the showstopper. When configured in bridge or passthrough mode:

A) dnsmasq offers the WAN IP as a static lease to LAN clients:

dnsmasq-dhcp: DHCP, static leases only on 192.0.0.2, lease time 1h

or:

dnsmasq-dhcp: DHCP, static leases only on 25.73.59.71, lease time 1h

The 7.21 changelog says “DHCP server: added validation to prevent bridge and passthrough IP address usage for static leases” — but this is still happening on 7.21.

B) LAN client gets whiplashed between addresses. During the eth0 link bounce, dnsmasq restarts. The client requests its previous LAN IP (192.168.12.213), gets NAK’d (“wrong address” or “static lease available”), does DISCOVER, and gets offered the WAN CGNAT IP. Client then can’t route traffic because it has a CGNAT address with no actual path to the internet.

C) “Failed to connect to the switch” error in bridge mode:

netifd: mob1s1a1: Failed to connect to the switch. Use the "list" command to see which switches are available.

The TRB501 doesn’t have a managed switch chip, so this bridge plumbing step fails. This appears to prevent the actual bridging of rmnet_data0 into br-lan.

D) Stale routing entries on reconnection:

netifd: mob1s1a1: RTNETLINK answers: File exists
netifd: mob1s1a1: RTNETLINK answers: File exists
netifd: mob1s1a1: RTNETLINK answers: File exists
netifd: mob1s1a1: RTNETLINK answers: File exists

Routes from the previous connection attempt aren’t cleaned up during teardown, so the new attempt fails to add them.

E) T-Mobile CGNAT addressing makes passthrough pointless anyway. T-Mobile is assigning CGNAT addresses — I’ve seen 192.0.0.2/27 (RFC 7335), 25.73.59.71/28, 25.77.95.28, and 28.42.255.181. These are all behind carrier NAT, so passing them through to a LAN client provides zero benefit over NAT mode.

F) MTU mismatch. IPv4 gets MTU 1472, IPv6 gets MTU 1500 from the operator. The device warns about this but doesn’t appear to handle it cleanly in bridge/passthrough.

Test Matrix

Mode FW 7.19.4 FW 7.21 Internet Works?
NAT :white_check_mark: Works :white_check_mark: Works Yes
Bridge :cross_mark: Broken :cross_mark: Broken No - “Failed to connect to the switch”, WAN IP leaked to LAN
Passthrough :cross_mark: Broken :cross_mark: Broken No - WAN IP static lease, DHCP chaos, stale routes

What I Need

  1. Updated RG520NE modem firmware to address the baseband crashes (both the EX:kernel and dsm_queue.c signatures).
  2. Fix for eth0 link bounce — the r8125/IPA driver path should not require a full NIC reinitialization on every mobile interface change.
  3. Fix for bridge/passthrough mode — specifically the “Failed to connect to the switch” error, the WAN IP being offered as a DHCP static lease, and the stale routing entries.

Happy to provide full system logs or run any diagnostic commands. I have logs covering clean boot → NAT → bridge → passthrough transitions with full syslog output.

2 Likes
2

Hi there,

For troubleshooting and log collection purposes, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 17959.

Thank you,
M.

4

I’ve checked spam and various folders and don’t see an email, was this a DM in the chat system or something else?

5

Hello,

I’ve re-sent the e-mail. Kindly try checking again. It should appear within your email inbox that your forum account is registered on.

Regards,
M.

6

And I filled out and submitted the form, however it doesn’t lead me to a page to upload any tech support files‽

7

Hello,

I’ve sent you the e-mail already, you simply have to reply to it with the details.

Regards,
M.

8

Hi there,

I got a partial response to the following:

A) This change is meant for WebUI/API to prevent creating a static lease with the address of your mobile operator.

B) Seems like the client device doesn’t have a default route. Could you please double-check?

Regards,
M.

9

Hi Matas, thanks for the partial response — happy to dig into both points.

On A) — That clarification makes sense. The 7.21 changelog wording was ambiguous, so good to know the validation is a WebUI/API guard for manual static lease creation, not a change to how the bridge/passthrough data path itself operates. Understood.

On B) — The test environment here is about as minimal as it gets: a Mac Mini acting as a plain DHCP client, connected directly to the TRB501’s 2.5GbE port with a single ethernet cable. No switch, no router in between, no static routes or manual network configuration on the client. The only thing non-default on the Mac is a 192.168.12.0/24 alias on the same interface so I can reach the TRB501’s management UI while testing.

So if the client doesn’t have a default route after the DHCP exchange, that’s coming from the TRB501 side — the client will accept whatever dnsmasq hands it. Happy to capture ipconfig getpacket en0 (macOS equivalent of the full DHCP lease details including router option) and netstat -rn output to show exactly what the client is receiving, if that would help move things forward.

That said, I suspect the deeper issue isn’t the DHCP options themselves but the L2 path. In bridge mode specifically, the “Failed to connect to the switch” error suggests the code path that’s supposed to bridge rmnet_data0 into br-lan is hitting a wall because the TRB501 doesn’t have a managed switch chip. If that bridging step fails, the client could have a perfect default route and still have no path to the internet — the packets have nowhere to go at L2.

Let me know what diagnostics would be most useful and I’ll get them captured cleanly. I’ve got logs covering the full boot → connect → mode-change sequences for NAT, bridge, and passthrough on both 7.19.4 and 7.21 — happy to share whatever helps.

1 Like
10

Hello,

Thank you kindly, in the case that we’ll need anything or have further answers - I’ll reach out to you.

Regards,
M.

11

Thanks for the response, Matas.

One more item I’d like to raise — my TRB501 is running modem firmware RG520NEBDCR03A01M4G. Based on Quectel’s own release notes (V0305), A01 is a pre-mass production firmware release for engineering samples. The latest available from Quectel is A05 (RG520NEBDCR03A05M4G), and the changelog from A01 to A05 is substantial.

I’d like to request a modem firmware update before we invest more troubleshooting cycles. Here’s the supporting context:

Teltonika community:

  • TRB501 modem firmware update (thread #16393) — another TRB501 user confirmed with Quectel that A01 is pre-production and A05 is current. Teltonika support ultimately assisted with the update.
  • TRB500 constant crashing (thread #17364) — TRB500 modem crashes resolved by modem firmware update. Different crash signature than mine, but same resolution path.
  • Thread #16039 here on the community — another TRB501 with recurring modem crashes under investigation.

Quectel forums (same RG520N modem family):
Multiple threads document RM520N/RG520N crashes, T-Mobile 5G disconnects during band aggregation, and passthrough/bridge issues — all on the same modem family, with firmware updates as the common resolution path.

I currently have the device in a testing and validation phase — I’m not comfortable relying on it given the issues I’ve documented. I’m happy to do forward and backward firmware updates as needed to help isolate whether these crashes are resolved in newer modem builds. Four revisions of fixes shouldn’t be sitting on the table while we troubleshoot.

Happy to fill out whatever form is needed — I already have a support ticket open via email, or I can use ticket ID 17959 if that works.

Appreciate the help.

12

Follow-up with the Quectel forum references I mentioned above (link limit on my previous post):

And two more that are relevant but I’ll reference by title since I’m probably still at my link limit:

  • Quectel forum thread #37656 “Disconnects on T-Mobile 5G” — RM520N disconnects on T-Mobile specifically, traced to modem behavior during band aggregation.
  • Quectel forum thread #42233 “RG520N-EB WAN IP Passthrough” — same modem family with passthrough/bridge issues.
13

Regarding thread #16393 - they offered to upgrade my modem firmware through a remote session, which I did appreciate.

However, the combination of shipping units for “demanding environments” with pre-mass production firmware and not having a scalable approach for upgrades was so bewildering to me that I ended up selling the unit.

14

Hi there,

Of oourse, that is something that we can try & do - I have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 17959. Once the form has been filled out, please wait patiently until I reach out to you through e-mail.

Thank you,
M.

15

Submitted :blush:

1 Like
16

Update — March 24, 2026

After a month of working this through email support, forum threads, and direct contact with Quectel’s engineering team, here’s where things stand:

Modem firmware situation:
Matas confirmed that the latest modem firmware Teltonika has on file is the same A01 build that shipped with the device — RG520NEBDCR03A01M4G_OCPU_02.200.00.000. Nothing newer available on their end.

However, Quectel’s own field application engineer confirmed two critical things:

  1. The OCPU firmware builds are Teltonika’s builds based on Quectel’s QuecOpen SDK — they are not Quectel firmware. Teltonika owns the build and release process.
  2. The A01 base revision is classified in Quectel’s release notes as pre-mass production firmware for engineering samples. The current production revision is A05 (RG520NEBDCR03A05M4G), four revisions ahead, with a substantial changelog.

This was previously documented by another TRB501 user in thread #16393, where Quectel directly told them A05 is current and Teltonika’s support team (Marija) offered a remote session to perform the update.

What this means:
The path to updated modem firmware requires Teltonika to rebuild their OCPU package against the A05 SDK base from Quectel. This isn’t something end users can do, and Quectel has explicitly warned against flashing non-OCPU firmware on TRB501 devices.

Bridge/passthrough mode:
Justinas from Teltonika confirmed in thread #18074 that R&D is aware of the bridge mode performance issue — traffic in bridge/passthrough mode goes through the device’s firewall rather than bypassing it, cutting throughput by 2-3x. No ETA on a fix.

Other TRB501 users seeing the same issues:
Since my original post, several more threads have appeared with TRB501 users on the same A01 modem firmware hitting modem crashes (thread #18183 — 90-second reboot loops in 5G mode), bridge mode throughput caps (thread #17601), and speed regressions after device firmware updates (thread #18394).

I’ve escalated the modem firmware issue to Teltonika’s sales and engineering contacts and have Quectel’s engineering team CC’d. Will update this thread when there’s progress.

If you’re a TRB501 owner experiencing similar issues, check your modem firmware version in the WebUI — if it shows RG520NEBDCR03A01M4G, you’re on the same pre-production build.