gsmctl -A “AT+QMTUINFO”
+QMTUINFO: 1,1500,-
+QMTUINFO: 2,1500,1500
this is the same, regardless if using nat-mode or bridge-mode.
If I reduce MTU-size as suggested, it affects the MTU-size on rmnet_data0,
but not the output from gsmctl -A “AT+QMTUINFO”.
Reducing MTU-size did not affect the Ookla Speedtest, at least not in a positive way.
1500 bytes is the default MTU size, so we see that the issue is not MTU-related. Better to check anyway.
Have you enabled “Software flow offloading” in Network->Firewall->General settings ?
It is hard to make sense of the results you have reported above. Seems firewall / iptables / nft processing time.
What do you obtain if you execute the speed test when connected directly to the TRB ?
If I connect directly to TRB500, which was where I started first, I have full speed. But I have more than one computer and I want to have separate networks behind TRB500.
Then I tried with OPNsense behind TRB500 (as Router A). This lead me to think for a long time I had problems with my 5G-connection (remember I can’t see if I am connected to a 5G-band in TRB500, see other thread). Every time I connected to computer directly to TRB500 it suddenly worked. So when using OPNsense in-between it looked like TRB500 suddenly only used 4G.
I completely agree, it doesn’t make sense at all.
With Network->Firewall->General settings, I assume you mean in TRB500?
No such setting available I’m afraid, so “no, I have not enabled it” 
Is it possible to set from the CLI?
As I see it, TRB500 has a combability issue with OPNsense since it is not possible to do the firmware update through TRB500 when it is used in nat-mode. Workaround for that is to use brige-mode.
What I have most problem with is that I can’t get full 5G-speed with Speedtest though the combination OPNsense → TRB500 (regardless of nat- or bridge-mode).
I think this last issue is not anything I can blame TRB500 for since it works fine if I use something else than OPNsense before TRB500.
I am OK with this, I don’t think there is anything in TRB500 that needs to be corrected (more than that I can’t see any 5G-channels listed in it as reported separately).
However, if someone has any other ideas of what to test I can do that.
No such setting available I’m afraid, so “no, I have not enabled it”
it is a little below, in Routing / Nat offloading
Good. One issue at a time.
When connected directly, do you still experience the FIN ACK issue ?
There is nothing in “Routing/NAT offloading”. I.e. it is shown expanded in my last picture. If I click on it, the arrow down just flips and point upwards.
Yes on the last question, I.e. that is what happens in the table above where OPNsense is used in Router A. I.e. the FIN ACK issue was related to OPNsense update, not the speed-issue.
So I’m afraid this is two issues in the same thread, but at least that is something I have learned now and wasn’t aware of when I created this thread
Hello,
Our RnD team is currently investigating this issue. Perhaps you could provide instructions on how to reliably replicate the issue you are facing?
Additionally, does the issue only happen with OPNsense, or are any other operating systems affected as well?
Best regards,
Hello, thanks for looking into this.
Windows and Linux / Debian works. Trying to update OPNsense is the only serious problem I found so far.
Hopefully, this procedure will help you see the issue…
Download OPNsense from Download - OPNsense® is a true open source firewall and more
(I used 23.1.11 and earlier, but since they don’t recognize the problem and hence can’t fix it,
the actual version is probably not important.)
Install on suitable hardware Hardware sizing & setup — OPNsense documentation
Easiest if using two ethernet interfaces and try to use LAN-port when talking with OPNsense.
(Default rules allow access on LAN-port but not on WAN).
Read the installation manual Installation and setup — OPNsense documentation
I suggest using static IPv4 addresses both for LAN and WAN.
(DHCP also works, but I have had some issues some times)
First login to the GUI https://yourconfiguredLANaddress
System->Firmware->Settings->Mirror: Chose c0urier.net (HTTPS, Lund, SE)
(This mirror doesn’t have ipv6 which helps if your own ISP doesn’t support ipv6. I.e. this is the setting I use.)
SSH into the OPNsense router (or through RS-232 port if available)
Chose 8 (Shell)
pkg update -f
if successful it will complete within seconds
if unsuccessful percentage counter will stall (most often at 0%), hit Ctrl-C to interrupt.
This “Check for update” is normally done in the GUI. But when using TRB500 as gateway as long as the problem exist, you will have to reboot OPNsense each time you notice that the update doesn’t work. There are background processes that never terminate when using the GUI.
In the shell, using ‘pkg update -f’, you don’t need to reboot if you interrupt with Ctrl-C.
I strongly suggest you do the first setup of OPNsense having the WAN-port connected to some other route to internet than through TRB500 (and probably other devices based on the same firewall rules).
When you have reached the point above where you can run a ‘pkg update -f’ from the shell without any issues, then it is time to move the WAN-cable to TRB500. Of course adjusting WAN address and default gateway first.
‘ping c0urier.net’ must work, then you can try ‘pkg update -f’
When everything works, you should be able to click on “check for updates” on the dashboard in the GUI.
My TRB500 is using TRB5_R_00.07.04.3
