After firmware RUT9M_R_00.07.22.1 was installed on two RUT956 routers, browser requests to the WebUI returned ERR_CONNECTION_REFUSED; that result points first to a web endpoint that is not accepting the connection, not to a rejected username or password.
Which hop rejects the browser request?
Trace the request from the client to the router before changing firmware or credentials. The browser resolves or uses the entered address, sends a TCP connection request to the router, and then expects an HTTP or HTTPS service to respond. A refusal occurs before the WebUI can present a login page. A bad password normally produces a login failure after the page loads; it does not explain a refused TCP connection.
In this case, the reported path was a local connection to 192.168.1.1. Ethernet link activity appeared briefly, then the client showed no connection. That observation makes the physical link and the router’s address assignment worth checking before diagnosing the application, but a blinking Ethernet indicator alone does not prove the client has a usable IP route.
| Reading | What it indicates | Next check |
|---|---|---|
| Ethernet link/activity indicator | Some physical link activity is present; it does not confirm correct IP settings or a working web service. | Check client address, subnet, route, and reachability of 192.168.1.1. |
| Browser reports connection refused | The requested web endpoint did not accept the connection. | Test HTTP and HTTPS separately, then inspect the web server over an available management path. |
| Login page appears but credentials fail | Network path and web service respond; the issue is now authentication. | Use credentials appropriate to the current reset state. |
| Page loads but menus or content are missing | The connection is established, but WebUI assets or menu data may be unavailable. | Inspect the specified menu file and firmware state. |
Does the client reach the router on the expected address?
Read the client’s interface address and subnet, then confirm that the cable is seated and the link remains active. Connect directly to the router’s Ethernet interface where practical, and avoid relying on a remembered browser bookmark or a stale client route. The reported address was 192.168.1.1; verify that the client is configured to reach that address on the directly connected network before moving to application diagnostics.
Try both schemes using the same address: http://192.168.1.1 and https://192.168.1.1. The router may expose the interface on one scheme while the other is unavailable or redirected. Record the exact browser result for each attempt. A refusal on both schemes, with a working Ethernet path and successful management access by SSH, narrows the fault to the router’s WebUI service or application layer rather than a browser credential problem.
If neither browser attempt reaches the router and SSH is also unavailable, stay at the network-path stage: verify link, client addressing, and whether the router is reachable at the expected local address. Do not infer that the WebUI is damaged from link lights alone.
What does the uhttpd service report over SSH?
When SSH works, use it to distinguish a web-server service problem from a browser-side problem. The reported recovery path used PuTTY for SSH. The router accepted the root account with the user's personal password before the downgrade. Credentials depend on reset history: after a factory reset, the username and password can be found on the product label; without a reset, the reported username was root and the personal password remained in use. Do not treat default credentials as universal across reset states.
Run the service checks and retain their exact output:
/etc/init.d/uhttpd restart
/etc/init.d/uhttpd statusThe reported status was running after restart. That confirms the init script reports the service running, but it does not by itself confirm that the browser can connect, that the service is bound to the expected interface and port, or that WebUI content is intact. After restarting, retry both HTTP and HTTPS from the client. If refusal persists, check service logs and listener/socket state using the router’s available diagnostic facilities; record the bound address, port, and any startup error rather than guessing at a port or configuration value.
| Observation | Interpretation | Next action |
|---|---|---|
uhttpd does not report running |
The server process/service is not currently active. | Restart it, capture errors, and retest the browser. |
uhttpd reports running but browser still refuses |
Service status alone does not establish an accepting listener or healthy WebUI. | Inspect listener/interface and startup diagnostics, then examine UI files. |
| Browser connects after restart | The immediate failure was service availability. | Retest after reboot to determine whether service startup remains reliable. |
Is the WebUI menu file present at the correct path?
The suggested application-level check names /usr/share/vuci/menu.d/menu.json. One command attempt used /ust/share/vuci/menu.d/menu.json and returned “No such file or directory.” The path contains a typo: /ust is not the instructed /usr path. That failed command does not establish whether the intended menu file exists or is missing.
Check the exact path before removing anything. The proposed repair was:
rm /usr/share/vuci/menu.d/menu.json
rebootUse this targeted change only when diagnosing the menu/application issue and after confirming the path and file state. Removing the file and rebooting was proposed as a test; no result showing that it restored the interface was reported. If the browser is still refusing the connection, a menu file issue may not be the only fault, because a refused connection can occur before menu content is served.
A separate API test returned Error: 4 for /sbin/api GET /system/device/status. Record that result for support, but do not assign it a meaning without the corresponding router diagnostics or documentation. It does not substitute for checking whether the browser can establish a connection.
Should you recover by reinstalling or changing firmware?
The WebUI returned after installing an older firmware version, and the router was reset to factory defaults during that downgrade. A firmware change is therefore a demonstrated recovery route for this case, but the exact older version was not identified. The downgrade result does not identify the precise fault in RUT9M_R_00.07.22.1 or guarantee that a later upgrade will succeed.
Before changing firmware, record the installed version and the version from which the update was made; those details are needed to compare the transition and provide useful support information. If the interface is accessible, preserve configuration information before a clean upgrade. A recommendation given for this case was to upgrade to the latest firmware without keeping existing settings. Treat that as a clean-install path: it can remove device settings, so plan to restore configuration deliberately rather than expecting settings to survive.
Bootloader recovery was suggested as another way to reflash the device, but the bootloader WebUI did not work in this case. Do not repeat that route as if it were confirmed available. SSH via PuTTY was the working access route; if the device cannot be reached through SSH or its recovery interface, use the manufacturer’s support channel for model- and firmware-specific recovery instructions.
How do you close the recovery branch and verify the result?
Use the least disruptive branch that still provides access: verify Ethernet/IP reachability, test both browser schemes, restart and inspect uhttpd, then check the exact menu path. If the service remains unavailable or the firmware state is suspect, compare firmware versions and proceed with a planned recovery or clean upgrade. Keep a record of whether the action was a service restart, menu-file repair, downgrade, or upgrade; otherwise a working result will not identify which change resolved the fault.
- After the repair or firmware operation, confirm the client can reach
192.168.1.1over the local link. - Open
http://192.168.1.1andhttps://192.168.1.1; verify that the WebUI login page loads rather than returningERR_CONNECTION_REFUSED. - Sign in using credentials for the current reset state, then check that the interface renders its menus and pages.
- Reboot the router and repeat the connection and login checks. A successful post-reboot test verifies that the web service and UI return after startup, not merely after a manual restart.
Why does the RUT956 WebUI return ERR_CONNECTION_REFUSED?
Why does the RUT956 WebUI return ERR_CONNECTION_REFUSED?
The browser cannot establish a connection to the requested web endpoint. Check the IP path and test HTTP and HTTPS separately, then inspect uhttpd over SSH.
Why does uhttpd say running while the page still refuses to load?
A running service status does not prove that a listener is accepting connections on the router address or that the WebUI files are healthy. Check listener details and service diagnostics, then retry from the client.
Why does the menu.json removal command say no such file?
Check the spelling and use the suggested path /usr/share/vuci/menu.d/menu.json. The attempted path was /ust/share/vuci/menu.d/menu.json, which omits the correct r in /usr.
Why did downgrading the RUT956 erase my settings?
The downgrade was reported to erase device settings automatically. Plan to restore the configuration after recovery; an additional factory reset is not needed solely to erase settings again.
How do I verify the RUT956 WebUI recovery?
After reboot, reach 192.168.1.1, load the login page over HTTP or HTTPS, sign in with the credentials for the current reset state, and confirm the menus render.