Hi,
We searched through all the possible posts regarding the bridge mode problem with the TRB500 and TRB501 and have found no solution yet. All the existing topics got closed and always end with somebody from Teltonika redirecting the problem to a ticket or privat conversation.
How is it possible that after more then two years we still don’t have a working bridge mode on the TRB500? (and as i read, the “new” TRB501 also has the same problem.) We bought multiple TRB500 for deployment at our locations and clients but have them laying in boxes as our test setup still can’t achieve more then 200mbits in bridge mode (but easily 500-600mbits in NAT, maximum what our SIM provider gives us).
Our Test-Setup right now is running the latest Device and Modem Firmware: Device: TRB500_R_00.07.21.1 Modem: RG501QEUAAR12A11M4G
Stability is fine(-ish) after the upgrade to the newest Modem Firmware, thanks to the user @gt-solutions (PatrickWegmann on Github). Sometimes the UniFi Firewall can’t aquire the IPv4 address. Newest Device Firmware with the “Local DHPCv4 lease off” toggle fixed it for us.
What we observed so far:
NAT mode perfomes well, with low latency and full speed. Using a TRB500 and QuMax Omni
Bridge mode with same hardware barely gets 200, more like 160-180, latency is very high and can’t be fixed with any limiters or queues
While using bridge mode and running the speedtest, CPU Load spikes to an extreme. WebUi sometimes freezes.
Random disconnects at night (around 01:00), we have to clarify with our ISP but its probably some routine from their side. Problem is: the TRB500 sometimes doesn’t reconnect and has to be power-cycled. Happens around 3-4 times in a month.
Very often we encounter the error “Events Log could not be accessed because the database is being optimized.” Event Logs then don’t work. After multiple restarts sometimes they start working, till we restart again. Then they are broken again.
Our goal is to finally have a working, full-speed bridge mode modem. We have yet to find a solution to this.
Does any solution finally exist or should we just write off our loses and buy a different product?
Our research and development department is aware of this issue and they are working on a fix. The reason for this issue is that when going into bridge or passthrough mode, all traffic goes through our device’s firewall, which our device has to handle, essentially slowing speeds by 2 or 3 times.
There is no ETA currently, but as soon as I get an update, I will get back to you.
Thanks for answering my post.
Is there an ETA at all, as this issue dates back already to around January 2024 (first posts i found concerning this issue, so over two years of working on this problem)?
In some posts other Teltonika Members speak of a problem with the software/framework provided by Quectel, the maker of the Chipset you guys used in the TRB500.
I don’t really unterstand the point that it goes through the “device’s firewall” as the whole point of bridge mode is to disable and bypass all of that. To me it looks more like a Software defect where the traffic in bridge mode is handled fully in software and not using specific hardware accelerators of the chipset?
As a counter argument: we tried the device in NAT mode running infront of our firewall, then set up a DMZ for the firewall. That way we semi-bypass double NATing and can access our services from outside by our IPv4. So TRB500 (in NAT mode) → DMZ → 3rd-Party-Firewall
By going this route we get the full advertised speed and kind of “bridge mode”. Its a highly janky solution and the firewall doesn’t get the real IPv4 on its interface tho.
It’s not a real solution but shows that it’s not a “device’s firewall” problem, as all the traffic now passes through the build in routing/firewall of the TRB500.
Sorry to say but to me this bridge problem is a fundamental software/driver problem of the OS running on the Quectel chipset.
Would be quite happy to hear atleast some real progress and ETA on that issue. Else we can’t really trust a promise “one day it will be fixed” kinda-deal.