When will the final version be released, and when will the German language be available on the device?
1 Like
Update:
The latest stable version 4.10 has been released. We recommend upgrading to the stable version If experiencing any issues with the beta firmware
2 Likes
Hello, thanks so much for the feedback.
Bug 1: we are currently checking the issue.
Bug 2: issue has been fixed in the stable version 4.10.
Bug 3: Sorry we cannot reproduce and may need some modem logs for analysis. Could you help to obtain some modem log for investigation. Here are the steps:
-
download this cfg file and place it to router’s /etc folder via scp
4G_5G_2.cfg (3.4 KB) -
prepare a USB drive with at least 4GB of free space and plug in to the router
-
log in to the ssh terminal, enter the command below, please replace the /tmp/mountd/disk1_part1/ with the actual USB path :
diag_mdlog -u -i -f /etc/4G_5G_2.cfg -o /tmp/mountd/disk1_part1/ & -
access the admin panel, execute the following AT command:
AT+CFUN=0
AT+CFUN=1
- After router connects to the internet, connect mobile phone or PC to Mudi 7 and do some speedtests. Advised to test twice.
- Access the ssh terminal, enter the command below to stop the modem log capturing process:
diag_mdlog -k
Then export the diag_xxx folder from the USB drive. Kindly share the modem log and the speedtest results with us. Thank you very much
Thanks Cathy. Updated to the stable 4.10 release today.
Bug 2: confirmed fixed on stable 4.10 — the 5G bandwidth now shows 100 MHz.
Bug 3 (AMBR) — please drop it, my mistake. The panel still shows 150 / 56 Mbps on stable, but I checked what the modem itself reports:
AT+QNWCFG="lte_ambr"
+QNWCFG: "lte_ambr","internet.a1.bg",150000,56000
So the panel shows exactly the APN-AMBR that A1 signals for the bearer; the higher speeds I measure just mean A1 does not enforce it. Not a firmware issue — at most the label could say "APN-AMBR signalled by the network (not enforced/measured)" to avoid the confusion. I still captured the modem log with your procedure (diag_mdlog with 4G_5G_2.cfg, CFUN 0/1, two speed tests) and will send it to you by PM, in case it is useful.
Bug 1 on stable 4.10 — first observations: the modem settings differ from the beta (mode_pref = AUTO and nr5g_disable_mode = 0, where beta4 had LTE:NR5G / 1), and the first attach after the upgrade landed on a band-20 anchor of the neighbouring site (PCI 122) and still got n78 + n28 — a combination that never got 5G on the beta. I'll report whether the post-mobility loss of the NR leg still happens on stable over the next days. (The Cellular_debug.sh log attached to my post #40 was taken on beta4.)
Speed tests on 5G NSA right after the CFUN cycle (Speedtest by Ookla, A1 server): 468 / 76 Mbps, 14 ms and 307 / 68 Mbps, 13 ms.
2 Likes
Could you confirm whether any band lock or cell tower lock operation was performed on the Beta 4 version?
Based on the AT command response, the current network priority is set to LTE preferred, and SA mode is disabled. In this state, the modem will not preferentially register on NSA or SA networks.
AT+QNWPREFCFG="mode_pref" -> LTE:NR5G
AT+QNWPREFCFG="nr5g_disable_mode" -> 1
Hi Javon, no - no band lock, band masking, tower lock or operator lock was used on this router. On beta4 the Cellular Settings page showed Band Masking off and Lock Tower / Lock Operator "Unlocked".
What the modem reported on beta4 anyway, with those UI settings:
AT+QNWPREFCFG="mode_pref" -> LTE:NR5G
AT+QNWPREFCFG="nr5g_disable_mode" -> 1
AT+QNWPREFCFG="lte_band" -> 1:3:7:8:20
AT+QNWPREFCFG="nsa_nr5g_band" -> 28:78
and ubus call cellular.modem get_all_config showed network_mode: "AUTO" together with band_enable: true, band_filter_mode: 0 and exactly those band lists - so it looks like beta4 itself wrote these values (carrier-based preset?). After upgrading to stable 4.10 without touching any setting, the same modem now reports mode_pref = AUTO and nr5g_disable_mode = 0.
Two more observations that may help: even with LTE:NR5G / 1, the modem got n78 (+ n28) within seconds after every fresh registration (5 of 5 airplane-mode cycles / reboots); 5G was lost only after the modem moved to another LTE cell and was never re-added there. And the same site/anchor that never got 5G on beta4 (PCI 122) did get n78 + n28 on stable 4.10 right after the upgrade.
Hi , after upgrading to the latest version ( it says 4.0 1000release ) , my port forwarding settings stopped working.
I have wireguard tunnel and port forwarding set from LAN to wgclient1 . This was working before the upgrade but it's not anymore.
Is it possible to downgrade to fix this ?
Hello, what's the firmware version of the router before the upgrading?
I believe it was the 4.8.5 , i was only using the stable OTA releases.
Can I just use the “Firmware local upgrade” to downgrade to 4.8.5 downloaded from the download center ?
What's your port forwarding rule? Can you share a photo to check?
Additionally, please execute the following command in the ssh terminal and share the output with us. Thanks
Here are the port forwarding rules :
Can you please share the command i should run ? Thank you.
Is it possible to downgrade by uploading the 4.8.5 firmware ?
1 Like
Sorry, forgot to add it. Please check the output of this command:
cat /proc/port_forward_rules
Downgrading might help to fix it
1 Like
root@GL-E5800:~# cat /proc/port_forward_rules
=== Active Port Forwarding Rules ===
Rule #1:
Protocol: tcp
Public IP: 192.168.60.1
Public Ports: 3389
Internal IP: 192.168.30.33
Internal Ports: 3389
Type: Direct Forwarding
Rule #2:
Protocol: udp
Public IP: 192.168.60.1
Public Ports: 3389
Internal IP: 192.168.30.33
Internal Ports: 3389
Type: Direct Forwarding
Rule #3:
Protocol: tcp
Public IP: 192.168.60.1
Public Ports: 22000
Internal IP: 192.168.30.102
Internal Ports: 22000
Type: Direct Forwarding
Rule #4:
Protocol: udp
Public IP: 192.168.60.1
Public Ports: 22000
Internal IP: 192.168.30.102
Internal Ports: 22000
Type: Direct Forwarding
Rule #5:
Protocol: tcp
Public IP: 192.168.60.1
Public Ports: 3000
Internal IP: 192.168.30.105
Internal Ports: 3000
Type: Direct Forwarding
Rule #6:
Protocol: udp
Public IP: 192.168.60.1
Public Ports: 3000
Internal IP: 192.168.30.105
Internal Ports: 3000
Type: Direct Forwarding
Downgrading to 4.8.5 fixed the issue.
1 Like
Thanks for the details. In that case, this may have been a Beta 4 issue.
If no band lock, band masking, tower lock, or operator lock was enabled, the modem should not have been left with those restricted AT values. The current stable 4.10 behavior looks correct, since mode_pref is now AUTO and nr5g_disable_mode is 0.
Please continue observing whether cell reselection/handovers behave normally on stable 4.10, especially after the modem moves to another LTE anchor cell.
If the test environment is still available, could you also help query and share the results of the following AT commands?
AT+QNWLOCK="common/4g"
AT+QNWLOCK="common/5g"
1 Like
Hi Javon, the beta 4 environment is no longer available — I upgraded this unit to stable 4.10 on 1 Sep (settings retained), so the QNWLOCK values from beta 4 can't be read back anymore. What I have from beta 4 (29 Aug): the Cellular Settings page showed Lock Tower / Lock Operator "Unlocked" and Band Masking off, and the cellular.modem get_all_config dump had no lock entries — only the band lists and mode values I quoted above.
On stable 4.10 (queried today, no settings touched since the upgrade):
AT+QNWLOCK="common/4g" -> +QNWLOCK: "common/4g",0
AT+QNWLOCK="common/5g" -> +QNWLOCK: "common/5g",0
AT+QNWPREFCFG="mode_pref" -> AUTO
AT+QNWPREFCFG="nr5g_disable_mode" -> 0
AT+QNWPREFCFG="lte_band" -> 1:3:5:7:8:20:28:32:38:40:41:42:43
AT+QNWPREFCFG="nsa_nr5g_band" -> 1:3:5:7:8:20:26:28:38:40:41:75:76:77:78
AT+QNWPREFCFG="nr5g_band" -> 1:3:5:7:8:20:26:28:38:40:41:75:76:77:78
I'll keep observing reselection/handover on stable, especially after the modem moves to another LTE anchor, and report back with data.
1 Like
Hi, we can reproduce this issue. I've submitted to the dev team for investigation.
Thanks for the information
2 Likes