RUTX50 CLI Broken

Networking Solutions Issue
1

Same problem as WebUI CLI closing connection

It segfaults and no configuration can do anything about it. It’s pretty obvious this is a software regression given it segfaults, if software was operating normally it would not segfault but just report what the problem is.

  • Model: RUTX50 (RUTX5000XXXX)
  • Firmware: RUTX_R_00.07.23.6
  • Package: uhttpd 2021-03-21-15346de8-17
  • Symptom: opening WebUI CLI (/cgi-bin/cli, ShellInABox) crashes uhttpd; browser shows “Session closed”
  • Kernel: uhttpd: unhandled page fault (11) at 0x00000004 — NULL+4 deref, PC at uhttpd text offset …41b4, faults on session-list iteration (r1=0, r5/r7 8 bytes apart)
3

I’m expierincing exactly the same on RUTX50 with firmware RUTX_R_00.07.22.3 while the CLI used to work just fine earlier with this version. I know I’m running on older firmware but was satisfied with functionality so why “fix if it aint broken?”.

4

Both of you need to reflash your devices with latest stable firmware but from boot loader mode.

5

Thanks for taking the time to reply but, sorry, there is always someone on this forum with this exact advise. Sadly it seldom solves anything and if you are out of luck you run into some new bug. But ok, to an extend you are right; I should upgrade because not a single company gives support if not up-to date. Next reply is often to reset to factory default and start over. This is my second Teltonika router and it is always the same song. If in the end it still doesn’t work, and if you are lucky, support will ask for logs and the waiting game starts…

But:

image
image227×258 6.61 KB

…and CLI still doesn’t work.

6 
          ____        _    ___  ____
         |  _ \ _   _| |_ / _ \/ ___|
         | |_) | | | | __| | | \___ \
         |  _ <| |_| | |_| |_| |___) |
         |_| \_\\__,_|\__|\___/|____/

           Teltonika RUTX series 2026

Device: RUTX50

Kernel: 6.6.126
Firmware: RUTX_R_00.07.23.7
Build: a6a80e3d4b
Build date: 2026-06-25 05:28:21

            ~ INTERNAL API USAGE ~

/sbin/api GET /system/device/status
/sbin/api POST /interfaces/config {…}

Docs: https://developers.teltonika-networks.com

root@Teltonika:~# logread -f
760 Wed Jul 1 18:04:11 2026 kern.err kernel: [ 678.466858] 8<— cut here —
761 Wed Jul 1 18:04:11 2026 kern.err kernel: [ 678.466922] uhttpd: unhandled page fault (11) at 0x00000004, code 0x805
762 Wed Jul 1 18:04:11 2026 kern.err kernel: [ 678.468835] [00000004] *pgd=00000000
763 Wed Jul 1 18:04:11 2026 kern.warn kernel: [ 678.475413] CPU: 2 PID: 21715 Comm: uhttpd Tainted: G O 6.6.126

7

Its mostly me. I tell everyone exact same thing because it always works unless its a real hardware issue. And that is extremely rare.

No. It doesnt matter if you flash the latest version or the older one. Its the process that matters.

Its how its done. No vendor can give you magic solution right away. Teltonika routers are complex devices and you need to rule out many things before you actually start troubleshooting. I understand frustration. I had my share of hair pulling with some other vendors. Believe me.

Getting to version 07.23.7 by updating from web gui is not the same as flashing 07.23.7 from boot loader mode. This is the part that many people fail to understand and they always reply with “but im already running latest stable firmware”. The point is, it doesnt matter. Reflashing from boot loader mode with exact same version solves many problems.

image
image752×804 42.4 KB

8

The need to reflash via bootloader is in my opinion a really bad bug.
But I will keep silent now because it is not my topic and I don’t have a real need for a working CLI because I mostly use SSH (PuTTY) anyway and that is working fine, even via ZeroTier VPN remotely.

9

I agree. But for people that dont want to wait and go through a long back and forth support process, and they need quick solution, this method helps. It helped me when i bought my device. Instead of starting new thread, i used forum search. Someone mentioned flashing from boot loader mode, i did it, and i never had issues since then. Quick easy fix.

10

Thanks.

There’s no way to properly flash the device with latest firmware from SSH/UI without using bootloader mode?

I have a tool that factory resets a device (calls “firstboot” over SSH), wait for it to come back up, then runs “sysupgrade -n /tmp/firmware.bin”.

From what you’re telling me this is still not enough and I should tell the operator to put it in boot loader mode, then automatize the firmware upgrade through the bootloader web interface?

I guess there’s no way to tell it “reboot in bootloader mode”.

11

This has to be done locally because once device is in boot loader mode, there are no DHCP services running on it. It has a manually assigned IP address and you need to set your client IP address manually as well. Once you do that, you access special web interface that only has browse button that allows you to select firmware BIN file and start the flashing process. All of this can not be done remotely. You need local access to the device and the client that performs the flashing process. See here for more details.

12

Yes, my app handles IP changes, ok thanks for confirming.

It’s a shame that there’s no way to properly factory reset a teltonika device without the reset button dance, but that’s how it is.

Quick question: some devices use 192.168.2.1 as the default IP (TRB500 I think). Is the boot loader guaranteed to always be on 192.168.1.1?

I guess I’ll find out :slight_smile:

13

I think TRB500 doesnt have boot loader mode. Its only on RUT9xx, RUT2xx and RUTXxx devices. Someone correct me if im wrong. For devices that do have it, its always static ip 192.168.1.1 which is hard coded in boot loader and completely independent on what you have set in your device manually.

14

Hello, @philippe.vaucher!

Thank you for the post.

We appreciate you reporting the issue.

Could you please clarify the following:

  • Via what IP/interface are you accessing the WebUI? (Public/private/VPN/RMS)
  • Are you able to use SSH to access the CLI?
  • If you are using a public IP to access the WebUI, have you tried a private one and vice versa?

We will do our best to investigate this issue, and for that, we need as much information as we can gather to find the root cause.

For anyone else experiencing the same issue, please feel free to answer the above-provided questions to help us diagnose this matter accurately.

Lastly, we were able to recreate the issue on our side; however, it was resolved by using bootloader mode. If possible, please do so on your devices as well and let us know if it helps.

Here’s a guide on how to perform it: RUTX50 Device Recovery Options - Teltonika Networks Wiki

Kind regards,
Laura.

15

@anon13159616 thank you for confirmation that flashing from boot loader mode solves the issue. My questions is, are there any plans on your side to make firmware update process more reliable ?

16

Hello!

Via what IP/interface are you accessing the WebUI? (Public/private/VPN/RMS)

Via wt0 which is netbird VPN running on the device.

Are you able to use SSH to access the CLI?

Yes SSH/WebUI works just fine. Just the web shell-in-a-box does not.

If you are using a public IP to access the WebUI, have you tried a private one and vice versa?

No, but let’s agree that using public/private IP should not matter at all and that shell-in-a-box segfaulting is the real issue here.

Philippe

17

Hello!

Thank you for your responses.

We have passed this case on to our R&D team for further investigation.

We will let you know once we have a response. In the meantime, please let us know if the bootloader menu fixes the issues you are experiencing.

Kind regards,
Laura.

18

Hello,

I can confirm the same bug on a CAP700 (ALTOS), firmware CAP7_R_00.07.24 — uhttpd dies with a segmentation fault on every CLI session continuation request (session creation itself succeeds), which the browser reports as “Session closed”. So the issue is not RUTX-specific. Full diagnosis with a deterministic curl reproducer and crash signature here: CAP700 (ALTOS) WebUI CLI "Session closed"-uhttpd segfault on session continuation (same bug as RUTX50 CLI Broken)