LuCI does not show login screen, nothing helpful in logs
Is there an existing issue for this?
- [x] I have searched among all existing issues (including closed issues)
screenshots or captures
Actual behaviour
Sone mid of April, LuCI does not show the login screen correctly. The browser redirects from / to /cgi-bin/luci as expected, but then nothing is shown. I can see some HTML code in the response, but it looks like something gets stuck on the server and the UI is never shown.
Using ubus monitor, I can see a lot of traffic, no errors, nothing helpful. No output in dmesg or logread. I have searched for helpful information how to debug LuCI, no idea what's going on. I am building my own version because I need support for ipsets in a non-ipv6 dnsmasq version.
Expected behaviour
LuCI login shoud be shown.
Steps to reproduce
Open LuCI from browser.
Additional Information
{
"kernel": "6.6.88",
"hostname": "GatewayDummi",
"system": "ARMv8 Processor rev 3",
"model": "Raspberry Pi 4 Model B Rev 1.5",
"board_name": "raspberrypi,4-model-b",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "SNAPSHOT",
"firmware_url": "https://downloads.openwrt.org/",
"revision": "r29352+9-0f9af6dcd9",
"target": "bcm27xx/bcm2711",
"description": "OpenWrt SNAPSHOT r29352+9-0f9af6dcd9",
"builddate": "1745959428"
}
}
What browsers do you see the problem on?
Microsoft Edge
Relevant log output
Please run /www/cgi-bin/luci as command on the cli and look fir errors or crashes.
Also check the browser JavaScript/ debug console for errors
When I run /www/cgi-bin/luci, I get the same HTML output that I can see when I observe the Response details on the browser's Network tab. See below. Also attached output from Browser console. It takes about 20 seconds before the ERR_INCOMPLETE_CHUNKED_ENCODING errors appear. The error happens on several browsers in two PCs and one mobile device, so it's not related to a specific device/browser version.
root@GatewayDummi:~# /www/cgi-bin/luci
Status: 403 Forbidden
x-luci-login-required: yes
content-type: text/html; charset=UTF-8
cache-control: no-cache
expires: 0
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
<!DOCTYPE html>
<html lang="en" >
<head>
<meta charset="utf-8">
<title>GatewayDummi - LuCI</title>
<script>
var mediaQuery = window.matchMedia('(prefers-color-scheme: dark)'),
rootElement = document.querySelector(':root'),
setDarkMode = function(match) { rootElement.setAttribute('data-darkmode', match.matches) };
mediaQuery.addEventListener('change', setDarkMode);
setDarkMode(mediaQuery);
</script>
<meta name="viewport" content="initial-scale=1.0">
<link rel="stylesheet" href="/luci-static/bootstrap/cascade.css?v=25.113.44500~9180f2a">
<link rel="stylesheet" media="only screen and (max-device-width: 854px)" href="/luci-static/bootstrap/mobile.css?v=25.113.44500~9180f2a" />
<link rel="icon" href="/luci-static/bootstrap/logo_48.png" sizes="48x48">
<link rel="icon" href="/luci-static/bootstrap/logo.svg" sizes="any">
<script src="/admin/translations/en"></script>
<script src="/luci-static/resources/cbi.js?v=25.113.44500~9180f2a"></script>
</head>
<body class="lang_en " data-page="">
<script src="/luci-static/resources/luci.js?v=25.115.55071~1355a6f-1745959428"></script>
<script>
L = new LuCI({ "media": "\/luci-static\/bootstrap", "resource": "\/luci-static\/resources", "scriptname": null, "pathinfo": null, "documentroot": null, "requestpath": [ ], "dispatchpath": [ ], "pollinterval": 5, "ubuspath": "\/ubus\/", "sessionid": null, "token": null, "nodespec": { "satisfied": true, "action": { "type": "template", "path": "admin_status\/index" }, "depends": { "acl": [ "luci-mod-status-index" ] }, "order": 1, "title": "Overview" }, "apply_rollback": 90, "apply_holdoff": 4, "apply_timeout": 5, "apply_display": 1.5, "rollback_token": null });
</script>
<section hidden>
<form method="post" class="cbi-map">
<div class="cbi-section">
<div class="cbi-section-node">
<div class="cbi-value">
<label class="cbi-value-title" for="luci_username">Username</label>
<div class="cbi-value-field">
<input name="luci_username" id="luci_username" type="text" autocomplete="username" value="root">
</div>
</div>
<div class="cbi-value">
<label class="cbi-value-title" for="luci_password">Password</label>
<div class="cbi-value-field">
<input name="luci_password" id="luci_password" type="password" autocomplete="current-password">
</div>
</div>
</div>
</div>
</form>
<hr>
<button class="btn cbi-button-positive important">Log in</button>
</section>
<div id="view">
<div class="spinning">Loading view…</div>
<script>
L.require('ui').then(function(ui) {
ui.instantiateView('bootstrap.sysauth');
});
</script>
</div>
</body>
</html>
<!-- Lua compatibility mode active: yes -->
luci/:1
GET https://192.168.10.1/cgi-bin/luci/ 403 (Forbidden)
luci/:1
GET https://192.168.10.1/cgi-bin/luci/ net::ERR_INCOMPLETE_CHUNKED_ENCODING 403 (Forbidden)
luci/:19
GET https://192.168.10.1/cgi-bin/luci/admin/translations/en net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK)
@jow- Sorry, accidentially closed this issue, it's still there.
@jow- I got this error on Firefox, I was able to login on Firefox, but LuCI not loading:
The only output I can see in the logs is
Thu May 1 12:12:22 2025 daemon.err uhttpd[6637]: [info] luci: accepted login on / for root from 192.168.179.169
When using ubus monitor while the page loads, I can see the first call -> 0c8c901b #0405f65b status: {"status":0,"objid":67499611} and then a long delay of about 10 seconds, before answer <- 0c8c901b #c3d95a95 invoke: {"objid":-1009165675,"method":"get_proto_handlers","data":{"ubus_rpc_session":"579e3c4482add07749bcf194dd0ecf6a"}} arrives.
I did some more things, the LuCI documentation (https://github.com/openwrt/luci/wiki/JsonRpcHowTo) says that curl https://192.168.10.1/cgi-bin/luci/rpc/auth -k --data following by a json should return a session ID. It does not on my system but results in a 404, a HTML response and an OpenSSL error.
Also, I tried to setup a completely new device (bcm27xx/bcm2711, rpi4) and the issue is also there. So it must have something to do with my config or my build. The config worked fine end of March and stopped working after easter holiday in mid of April.
@jow- Looks like RPC calls fail, while ubus cli works fine on the device. Any idea how to debug this?
When I start rpcd directly, I get:
root@GatewayDummi:~# rpcd
Unable to register ubus object luci.ddns: Invalid argument
Unable to register ubus object luci: Invalid argument
Unable to register ubus object luci.upnp: Invalid argument
Unable to register ubus object luci.wireguard: Invalid argument
I may have a pretty similar or at least related issue, which may give some more insight? At least from the /cgi-bin/luci/ request failing with and the 403 with no further error/output it feels similar.
I did a fresh install of 24.10.01 some weeks ago on an dap-x1860.
# ubus call system board
{
"kernel": "6.6.86",
"hostname": "dap-x1860-im18a-00",
"system": "MediaTek MT7621 ver:1 eco:3",
"model": "D-Link DAP-X1860 A1",
"board_name": "dlink,dap-x1860-a1",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.1",
"revision": "r28597-0425664679",
"target": "ramips/mt7621",
"description": "OpenWrt 24.10.1 r28597-0425664679",
"builddate": "1744562312"
}
}
Luci works fine over the default lan interface:
# curl -v "http://192.168.1.1/cgi-bin/luci/"
* Trying 192.168.1.1:80...
* Connected to 192.168.1.1 (192.168.1.1) port 80
* using HTTP/1.x
> GET /cgi-bin/luci/ HTTP/1.1
> Host: 192.168.1.1
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 403 Forbidden
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Keep-Alive: timeout=20
< x-luci-login-required: yes
< content-type: text/html; charset=UTF-8
< cache-control: no-cache
< expires: 0
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
<
<!DOCTYPE html>
[...]
<!-- Lua compatibility mode active: no -->
* Connection #0 to host 192.168.1.1 left intact
corresponding ubus monitor
-> e456e46e #e456e46e hello: {}
<- e456e46e #00000000 lookup: {"objpath":"system"}
-> e456e46e #00000000 data: {"objpath":"system","objid":2005103538,"objtype":-1539372080,"signature":{"board":{},"info":{},"reboot":{},"watchdog":{"frequency":5,"timeout":5,"magicclose":7,"stop":7},"signal":{"pid":5,"signum":5},"validate_firmware_image":{"path":3},"sysupgrade":{"path":3,"force":7,"backup":3,"prefix":3,"command":3,"options":2}}}
-> e456e46e #00000000 status: {"status":0}
<- e456e46e #778373b2 invoke: {"objid":2005103538,"method":"board","data":{}}
-> 1095b760 #e456e46e invoke: {"objid":2005103538,"method":"board","data":{},"user":"root","group":"root"}
<- 1095b760 #e456e46e data: {"objid":2005103538,"data":{"kernel":"6.6.86","hostname":"dap-x1860-im18a-00","system":"MediaTek MT7621 ver:1 eco:3","model":"D-Link DAP-X1860 A1","board_name":"dlink,dap-x1860-a1","rootfs_type":"squashfs","release":{"distribution":"OpenWrt","version":"24.10.1","revision":"r28597-0425664679","target":"ramips/mt7621","description":"OpenWrt 24.10.1 r28597-0425664679","builddate":"1744562312"}}}
-> e456e46e #778373b2 data: {"objid":2005103538,"data":{"kernel":"6.6.86","hostname":"dap-x1860-im18a-00","system":"MediaTek MT7621 ver:1 eco:3","model":"D-Link DAP-X1860 A1","board_name":"dlink,dap-x1860-a1","rootfs_type":"squashfs","release":{"distribution":"OpenWrt","version":"24.10.1","revision":"r28597-0425664679","target":"ramips/mt7621","description":"OpenWrt 24.10.1 r28597-0425664679","builddate":"1744562312"}}}
<- 1095b760 #e456e46e status: {"status":0,"objid":2005103538}
-> e456e46e #778373b2 status: {"status":0,"objid":2005103538}
<- e456e46e #00000000 lookup: {"objpath":"session"}
-> e456e46e #00000000 data: {"objpath":"session","objid":1788052494,"objtype":12389323,"signature":{"create":{"timeout":5},"list":{"ubus_rpc_session":3},"grant":{"ubus_rpc_session":3,"scope":3,"objects":1},"revoke":{"ubus_rpc_session":3,"scope":3,"objects":1},"access":{"ubus_rpc_session":3,"scope":3,"object":3,"function":3},"set":{"ubus_rpc_session":3,"values":2},"get":{"ubus_rpc_session":3,"keys":1},"unset":{"ubus_rpc_session":3,"keys":1},"destroy":{"ubus_rpc_session":3},"login":{"username":3,"password":3,"timeout":5}}}
-> e456e46e #00000000 status: {"status":0}
<- e456e46e #6a93840e invoke: {"objid":1788052494,"method":"get","data":{"ubus_rpc_session":"00000000000000000000000000000000","keys":["rollback"]}}
-> c7f5d12a #e456e46e invoke: {"objid":1788052494,"method":"get","data":{"ubus_rpc_session":"00000000000000000000000000000000","keys":["rollback"]},"user":"root","group":"root"}
<- c7f5d12a #e456e46e data: {"objid":1788052494,"data":{"values":{"rollback":{}}}}
-> e456e46e #6a93840e data: {"objid":1788052494,"data":{"values":{"rollback":{}}}}
<- c7f5d12a #e456e46e status: {"status":0,"objid":1788052494}
-> e456e46e #6a93840e status: {"status":0,"objid":1788052494}
corresponding wireshark tcp stream
00000000 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 6c 75 63 GET /cgi -bin/luc
00000010 69 2f 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 i/ HTTP/ 1.1..Hos
00000020 74 3a 20 31 39 32 2e 31 36 38 2e 31 2e 31 0d 0a t: 192.1 68.1.1..
00000030 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 72 6c User-Age nt: curl
00000040 2f 38 2e 31 33 2e 30 0d 0a 41 63 63 65 70 74 3a /8.13.0. .Accept:
00000050 20 2a 2f 2a 0d 0a 0d 0a */*....
00000000 48 54 54 50 2f 31 2e 31 20 34 30 33 20 46 6f 72 HTTP/1.1 403 For
00000010 62 69 64 64 65 6e 0d 0a 43 6f 6e 6e 65 63 74 69 bidden.. Connecti
00000020 6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a on: Keep -Alive..
00000030 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer -Encodin
00000040 67 3a 20 63 68 75 6e 6b 65 64 0d 0a g: chunk ed..
0000004C 4b 65 65 70 2d 41 6c 69 76 65 3a 20 74 69 6d 65 Keep-Ali ve: time
0000005C 6f 75 74 3d 32 30 0d 0a 78 2d 6c 75 63 69 2d 6c out=20.. x-luci-l
0000006C 6f 67 69 6e 2d 72 65 71 75 69 72 65 64 3a 20 79 ogin-req uired: y
0000007C 65 73 0d 0a 63 6f 6e 74 65 6e 74 2d 74 79 70 65 es..cont ent-type
0000008C 3a 20 74 65 78 74 2f 68 74 6d 6c 3b 20 63 68 61 : text/h tml; cha
0000009C 72 73 65 74 3d 55 54 46 2d 38 0d 0a 63 61 63 68 rset=UTF -8..cach
000000AC 65 2d 63 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63 61 e-contro l: no-ca
[...]
00000B9C 09 3c 2f 73 63 72 69 70 74 3e 0a 3c 2f 64 69 76 .</scrip t>.</div
00000BAC 3e 0a 0a 0a 0a 09 3c 2f 62 6f 64 79 3e 0a 3c 2f >.....</ body>.</
00000BBC 68 74 6d 6c 3e 0a 0a 3c 21 2d 2d 20 4c 75 61 20 html>..< !-- Lua
00000BCC 63 6f 6d 70 61 74 69 62 69 6c 69 74 79 20 6d 6f compatib ility mo
00000BDC 64 65 20 61 63 74 69 76 65 3a 20 6e 6f 20 2d 2d de activ e: no --
00000BEC 3e 0a 0d 0a >...
00000BF0 30 0d 0a 0d 0a 0....
Only thing I changed was adding a vlan interface with it's own subnet for management. Ssh, icmp and everything else works fine over the management interface too, but Luci does not:
# curl -v "http://10.23.18.100/cgi-bin/luci/"
* Trying 10.23.18.100:80...
* Connected to 10.23.18.100 (10.23.18.100) port 80
* using HTTP/1.x
> GET /cgi-bin/luci/ HTTP/1.1
> Host: 10.23.18.100
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 403 Forbidden
< Connection: Keep-Alive
< Transfer-Encoding: chunked
[... like some 1 or 2? minute timeout here?]
* Recv failure: Connection reset by peer
* closing connection #0
curl: (56) Recv failure: Connection reset by peer
corresponding ubus monitor
-> 5aae3609 #5aae3609 hello: {}
<- 5aae3609 #00000000 lookup: {"objpath":"system"}
-> 5aae3609 #00000000 data: {"objpath":"system","objid":2005103538,"objtype":-1539372080,"signature":{"board":{},"info":{},"reboot":{},"watchdog":{"frequency":5,"timeout":5,"magicclose":7,"stop":7},"signal":{"pid":5,"signum":5},"validate_firmware_image":{"path":3},"sysupgrade":{"path":3,"force":7,"backup":3,"prefix":3,"command":3,"options":2}}}
-> 5aae3609 #00000000 status: {"status":0}
<- 5aae3609 #778373b2 invoke: {"objid":2005103538,"method":"board","data":{}}
-> 1095b760 #5aae3609 invoke: {"objid":2005103538,"method":"board","data":{},"user":"root","group":"root"}
<- 1095b760 #5aae3609 data: {"objid":2005103538,"data":{"kernel":"6.6.86","hostname":"dap-x1860-im18a-00","system":"MediaTek MT7621 ver:1 eco:3","model":"D-Link DAP-X1860 A1","board_name":"dlink,dap-x1860-a1","rootfs_type":"squashfs","release":{"distribution":"OpenWrt","version":"24.10.1","revision":"r28597-0425664679","target":"ramips/mt7621","description":"OpenWrt 24.10.1 r28597-0425664679","builddate":"1744562312"}}}
-> 5aae3609 #778373b2 data: {"objid":2005103538,"data":{"kernel":"6.6.86","hostname":"dap-x1860-im18a-00","system":"MediaTek MT7621 ver:1 eco:3","model":"D-Link DAP-X1860 A1","board_name":"dlink,dap-x1860-a1","rootfs_type":"squashfs","release":{"distribution":"OpenWrt","version":"24.10.1","revision":"r28597-0425664679","target":"ramips/mt7621","description":"OpenWrt 24.10.1 r28597-0425664679","builddate":"1744562312"}}}
<- 1095b760 #5aae3609 status: {"status":0,"objid":2005103538}
-> 5aae3609 #778373b2 status: {"status":0,"objid":2005103538}
<- 5aae3609 #00000000 lookup: {"objpath":"session"}
-> 5aae3609 #00000000 data: {"objpath":"session","objid":1788052494,"objtype":12389323,"signature":{"create":{"timeout":5},"list":{"ubus_rpc_session":3},"grant":{"ubus_rpc_session":3,"scope":3,"objects":1},"revoke":{"ubus_rpc_session":3,"scope":3,"objects":1},"access":{"ubus_rpc_session":3,"scope":3,"object":3,"function":3},"set":{"ubus_rpc_session":3,"values":2},"get":{"ubus_rpc_session":3,"keys":1},"unset":{"ubus_rpc_session":3,"keys":1},"destroy":{"ubus_rpc_session":3},"login":{"username":3,"password":3,"timeout":5}}}
-> 5aae3609 #00000000 status: {"status":0}
<- 5aae3609 #6a93840e invoke: {"objid":1788052494,"method":"get","data":{"ubus_rpc_session":"00000000000000000000000000000000","keys":["rollback"]}}
-> c7f5d12a #5aae3609 invoke: {"objid":1788052494,"method":"get","data":{"ubus_rpc_session":"00000000000000000000000000000000","keys":["rollback"]},"user":"root","group":"root"}
<- c7f5d12a #5aae3609 data: {"objid":1788052494,"data":{"values":{"rollback":{}}}}
-> 5aae3609 #6a93840e data: {"objid":1788052494,"data":{"values":{"rollback":{}}}}
<- c7f5d12a #5aae3609 status: {"status":0,"objid":1788052494}
-> 5aae3609 #6a93840e status: {"status":0,"objid":1788052494}
corresponding wireshark capture
00000000 47 45 54 20 2f 63 67 69 2d 62 69 6e 2f 6c 75 63 GET /cgi -bin/luc
00000010 69 2f 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 i/ HTTP/ 1.1..Hos
00000020 74 3a 20 31 30 2e 32 33 2e 31 38 2e 31 30 30 0d t: 10.23 .18.100.
00000030 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 63 75 72 .User-Ag ent: cur
00000040 6c 2f 38 2e 31 33 2e 30 0d 0a 41 63 63 65 70 74 l/8.13.0 ..Accept
00000050 3a 20 2a 2f 2a 0d 0a 0d 0a : */*... .
00000000 48 54 54 50 2f 31 2e 31 20 34 30 33 20 46 6f 72 HTTP/1.1 403 For
00000010 62 69 64 64 65 6e 0d 0a 43 6f 6e 6e 65 63 74 69 bidden.. Connecti
00000020 6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a on: Keep -Alive..
00000030 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer -Encodin
00000040 67 3a 20 63 68 75 6e 6b 65 64 0d 0a g: chunk ed..
[... like some 1 or 2? minute timeout here?]
wireshark screenshot for packet flow/timing:
Opening http://10.23.18.100/cgi-bin/luci/ in firefox or chromium just loads forever / times out.
Manually executing /www/cgi-bin/luci gives identical output to @schuettecarsten 's earlier response. Besides some version string/name differences there is <!-- Lua compatibility mode active: no --> in my case, but no errors.
I was debugging luci some years ago, but this was in the lua days. I could not find any reasonable resource on how to debug this ucode setup further. Any hints?
If it turns out to be something completely different let me know and I will move this into a separate issue.
I just remembered I have a very similar setup at another place and could not remeber this being a problem earlier. The old setup is also a dap-x1860, but on 23.05.05:
# ubus call system board
{
"kernel": "5.15.167",
"hostname": "dap-x1860-ztk9-00",
"system": "MediaTek MT7621 ver:1 eco:3",
"model": "D-Link DAP-X1860 A1",
"board_name": "dlink,dap-x1860-a1",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "23.05.5",
"revision": "r24106-10cc5fcd00",
"target": "ramips/mt7621",
"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
}
}
accessing luci via the exact same vlan setup works there:
# curl -v "http://10.9.210.150/cgi-bin/luci/"
> GET /cgi-bin/luci/ HTTP/1.1
> Host: 10.9.210.150
> User-Agent: curl/8.7.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Keep-Alive: timeout=20
< x-luci-login-required: yes
< content-type: text/html; charset=UTF-8
< cache-control: no-cache
< expires: 0
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
<
<!DOCTYPE html>
<html lang="en" >
[...]
<!-- Lua compatibility mode active: no -->
Only difference besides the OpenWrt version is the vlan id being 210 instead of 23. I doubt it has somethig to do with vlans, but different interfaces in general tho.
Might this be related to 7e6741fbae9b122545e80aad8b9e3a5529c442ce and 852fc23b12d4a701ba724a40b6afd4d40a4ad68d? Those are the only commits which 'touch' anything to do with the luci core. I'm doubtful that it is those, since without them, and the new gcc15, they won't compile.
Things like this can also happen if jumbo frames are set on the send side or some switch in the middle, and the receive side is not set up for it.
Things like this can also happen if jumbo frames are set on the send side or some switch in the middle, and the receive side is not set up for it.
Just double-checked: No jumbo-frames.
I think i tracked my down to an mtu problem with shitty network hardware/drivers. (no jumbo frames tho) So i will hide the now irrelevant comments for now.
For me I can say, if I use ImageBuilder and create a image, it works. If I use the same revisions to build my own, the error is back.