CAP700 (ALTOS) WebUI CLI "Session closed"-uhttpd segfault on session continuation (same bug as RUTX50 CLI Broken)

Networking Solutions Issue
1

Hello,

This is a follow-up to RUTX50 CLI Broken. I can confirm the same bug on a CAP700 (ALTOS) — so this is not RUTX-specific. Below is a full diagnosis with a deterministic reproducer.

Device info:

  • Model: CAP700 (ALTOS)
  • Firmware: CAP7_R_00.07.24 (build 1309bb0f248, build date 2026-07-01)
  • Kernel: 5.15.144-perf+
  • History: WebUI CLI has never worked on this unit — through 07.22.3 → 07.23.7 → 07.24 (all upgrades performed via WebUI/RMS, keeping settings)

Symptom: CLI page loads normally, but clicking “Connect” immediately results in “Session closed”. No input is ever possible. SSH works 100% fine.

Architecture note (CAP700): the shellinabox package on this platform ships no shellinaboxd daemon. Its file list is only:

/etc/uci-defaults/7.22/99_cli_update
/etc/init.d/shellinabox
/usr/lib/uhttpd_cli.so
/etc/config/cli

So the web CLI runs as a uhttpd plugin (uhttpd_cli.so), served by the main uhttpd instance (-w /cgi-bin/cli).

Deterministic reproducer (via SSH, works every time):

# Step 1 - create a CLI session: works, returns HTTP 200 + JSON
S=$(curl -s -d "width=80&height=24" http://127.0.0.1/cgi-bin/cli | sed 's/.*"session":"\([^"]*\)".*/\1/')
echo "$S"
# -> e.g. Ye2w642Yb1icOmKEnNoLtA

# Step 2 - continue the session: uhttpd dies instantly
curl -i -d "session=$S&width=80&height=24" http://127.0.0.1/cgi-bin/cli
# -> curl: (7) Failed to connect to 127.0.0.1 port 80 after 0 ms: Error

After step 2, uhttpd is gone and procd respawns it (observed PID change 27971 → 28260 between ps and netstat). The respawned instance has an empty session list — which is exactly what the browser reports as “Session closed”, and it also invalidates the WebUI login session (explains the 401 cascade on /api/session/status I had previously diagnosed).

Crash signature confirmed: unlike on RUTX50, on CAP700 the crash is silent — nothing in logread and no kernel oops in dmesg. To capture it, I started an isolated foreground instance:

/usr/sbin/uhttpd -f -p 127.0.0.1:8080 -h /www -x /cgi-bin -w /cgi-bin/cli

Running the same two-step reproducer against port 8080 kills it with a plain:

Segmentation fault

printed to the console. So it is the same class of crash as the RUTX50 kernel oops (NULL deref during session handling) — SIGSEGV in uhttpd when processing a CLI session continuation request. Session creation always succeeds; the crash happens on the first request that references an existing session ID.

Additional data points:

  • 100% reproducible, on every attempt, from localhost and from LAN alike — so authentication, source IP, http_keepalive and firewall settings are not a factor (I had previously tested http_keepalive changes with no effect).
  • /etc/config/cli is default (enable '1', shell_limit '5').
  • The bug has survived three firmware versions upgraded via WebUI/RMS.

Questions:

  1. Since the workaround recommended in the RUTX50 thread is reflashing from bootloader mode: can you confirm this procedure is supported and safe on CAP700/ALTOS? (The CAP700 wiki does include a “Bootloader menu” section under Device Recovery Options, but an explicit confirmation for this platform would be appreciated.)
  2. Please pass to R&D that the affected code is shared across platforms (RUTX and ALTOS at minimum) — the crash is in the uhttpd CLI plugin (uhttpd_cli.so on CAP700) on session continuation.

Best regards,

XynthCode

3

Hello,

Thank you for reaching out.

Before proceeding with the recovery of the device, would you be willing to share a troubleshoot file from the device? This file will help us investigate the issue further. Please ensure that the file is taken before the recovery steps below are performed.

As the troubleshoot file can contain sensitive information, such as passwords, public IP addresses, serial numbers, and other confidential data, we have sent you a form to exchange the troubleshoot securely, which you will receive at the email address associated with your forum account. In the Ticket ID field of the form, please enter the ID of this thread: 20249.

Regarding recovery, for the CAP700 I recommend performing a manual firmware upgrade with the Keep settings option disabled rather than using the bootloader procedure.

To do so:

  1. Download the latest firmware image from our wiki (available here: CAP700 Firmware Downloads - Teltonika Networks Wiki ). I recommend using the latest firmware version, 07.24.1.
  2. In the WebUI, navigate to System → Firmware → Update Firmware.
  3. Set Update From to File.
  4. Disable the Keep settings option.
  5. Select the downloaded firmware image and start the upgrade.

Please note that this procedure resets the device to its factory defaults. Ensure you have local access to the device, as it could no longer be accessible remotely when restored to factory defaults.

If you encounter any issues during this procedure, or if reflashing through this procedure does not resolve the problem, please let us know. We can then investigate alternative recovery methods.

Regarding the issue itself, I have already forwarded your findings and reproduction steps to our R&D team. I also spent some time attempting to reproduce the issue on my own CAP700. Unfortunately, I was not able to reproduce the behavior, even when following the steps you provided. Nevertheless, our R&D team is now aware of your reproduction steps. The requested troubleshoot file will also provide them with additional information to assist in their investigation.

In summary, we would appreciate it if you could share the troubleshoot file with us using the form, perform the recovery procedure described above, and let us know how it goes.

Best regards,

Rokas V.

4

Hi Rokas,

Thank you for the response and the recommendations.

I’d like to share an update before proceeding with the full recovery
procedure with “Keep settings” disabled.

After your message, the router kept running without a restart, still on
firmware 07.24.1 (installed manually, but with settings retained - no
factory reset performed). A few days later, without any intervention on
my part to the configuration, the WebUI CLI spontaneously started working
correctly - I tested this multiple times, in separate sessions, with
different commands (including one longer, several-minutes-long session),
without a single “Session closed” occurrence or uhttpd crash.

In other words: the issue resolved itself on the same “old” configuration
we had previously suspected as a possible cause. This suggests the bug
might be state-dependent (process/memory state) rather than purely
configuration-triggered.

I sent the troubleshoot file from the period when the issue was still
occurring, as instructed (via email, after the form failed to deliver
the attachment on the first attempt).

For now I’m holding off on the full factory reset, so as not to disturb
this observation. I’m happy to perform it if R&D still considers it
necessary for further diagnosis - please let me know.

Best regards,
XynthCode

5

Hello,

Thank you for the information, and apologies for the delay.

As mentioned through the emails, I have forwarded troubleshoot file to our R&D team to support their investigation. I have also informed them that the CLI recovered by itself after an update to 07.24.1.

Should our R&D team ask for any additional information, or if I receive any further updates or findings, we will share them with you either here or via email directly.

Should any further issues or concerns arise, feel free to let us know.

Best regards,

Rokas V.