New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#1555 - (LUcI) Overview page hanging on "Collecting data..." #6811
Comments
jow-: Please provide the output of https://192.168.1.1/cgi-bin/luci/admin/status/overview?status=1 |
juanriccio: Hello and thank you. |
jow-: The JSON dump looks okay. Can you please open your browser debugger with F12 and look for runtime script errors while the page is refreshing? |
juanriccio: This is what Firefox tells me:
(several times) |
jow-: In the network tab, can you please expand one of the |
juanriccio: Yes, the response status is 200 OK. I've tested both https://router.lan/ and http:// to access the web interface - no difference. Manually resolving the local name to the IP address doesn't change anything, either. With https, there's the usual security warning about the certificate, but it's always been there. The issue is present with any browser I have available for testing. (latest) Firefox Quantum 60.0.1 (x64 Windows, Ubuntu) Maybe it isn't relevant, but the last two sections display correctly: Dynamic DNS Active UPnP Redirects |
jow-: In the debugger, can you switch to the JS source view / debugger and enable "pause on exceptions", then see if an error is triggered? To me it sounds as if the main status JSON is somehow corrupted. |
juanriccio: I don't know the JS debugger that much, but I launched it and set it to //Pause on all exceptions//, and I manually pressed the Resume (play-shaped) button after each pause. The script alternated pausing at line 107 and line 75 each time I resumed.
The error is always the same:
|
jow-: Please try disabling the HTTPS enforcement in uhttpd and see if the same problem happens on plain HTTP connections.
|
juanriccio: I don't think uhttpd was enforcing https anyway: I was already able to access the page via plain http. However, I entered those commands, and after the restart of uhttpd, I fetched the overview page via plain http. The problem remains. |
jow-: I am afraid I am out of ideas then. I am unable to reproduce the issue, even on avery slow device. At first it might be related to SSL but apprently it isn't. Do you see any cancelled requests in the network debugger? Do you use any extensions or AV scanner plugins? |
juanriccio: I don't see any warning signs in the network tab. Extensions and AV scanners can be ruled out, since previously the LuCI web interface worked correctly on all systems - including a legacy Win x86, a modern Win x64, and a modern Ubuntu x64. I think the problem is in OpenWrt itself - likely, some unlucky combination of modules and/or settings. I'm reverting to a previously working release for now. I hope someone else hits the same glitch and is able to report it with more useful info. Thanks for your time! |
arjendekorte: I see this happening from time to time to, since well over a year ago (so I doubt the root cause was introduced recently). It usually happens right after a reboot of the router and is 'fixed' by opening one of the other status tabs and then going back to the overview page. It may take a couple of retries, after that it is business as usual. I first noticed this after switching to a reverse proxy configuration and concluded (maybe in error) it must have something to do with that, with the proxy opening many connections in parallel. I never bothered to dig deeper into this. |
juanriccio: Hello Arjen, thanks for chiming in. Is that the same router? @Jo-Philipp-Wich - Is it worth it to file a bug in the LuCi section, maybe adding a link to this discussion? |
arjendekorte: No, different router (Netgear WNDR4300). |
juanriccio: Any idea how I can debug this from OpenWrt's commandline, to help spot the problem? |
ctbdavies: Also experiencing this problem with LuCI. Running LuCI Master git-18.176.34901 on multiple TP-Link TL-WR902AC v1 router. I have another running LuCI Master git-18.169.62979 where issue is not seen. I am using Firefox and Chromium browsers. |
camel: i have the same problem on newest mt7620 images ... eg: |
camel: meanwhile tested also mt7621 device with current trunk ... but no info on status page or on network->wireless overview. |
jow-: The missing assoclist is unrelated to the original report (where no dynamic data was loaded anywhere) and has been fixed yesterday with openwrt/luci@5818a90 - it just didn't lad in the snapshots yet. |
camel: thx pls, ticket can be closed. |
camel: hmm ... maybe a timing issue or to run the script for getting network and wireless device infos is taking more time as 5sec (xhr poll time) ? |
camel: i would recommend to increase the poll -> as there can be on much interfaces more time needed as "POLL 5sec" see: file: line: 201
who can take care to change this on trunk ? |
camel: |
juanriccio: The problem that I reported has disappeared as of Lede SNAPSHOT r8284-212aa33226. I don't know which exact release solved the issue, or what caused the issue for that matter. However, I suggest this task should be closed. |
mherbert: I just experienced this in Chrome (version 70.0.3538.77). In my case and thanks to Chrome's developer tools I finally root-caused it to corrupted data for the xhr.js file in the browser cache. Once I realized this I reloaded the page with Ctrl-Shift-R instead of just Ctrl-R and the problem was gone. I have no idea whether some bug in OpenWRT caused this initial corruption or something unrelated. LuCI lede-17.01 branch (git-18.201.27126-7bf0367) / LEDE Reboot 17.01.6 r3979-2252731af4 The following Javascript error was useful: xhr.js?v=git-18.201.27126-7bf0367:1 Uncaught SyntaxError: Unexpected token < Other Chrome accounts and the incognito mode were working fine on the same system: that was another useful clue. Below is how the start of the xhr.js URL looked like before I performed a forced refresh. It looks like data from some certificate? I don't think I ever used https, only http. http://192.168.1.1/luci-static/resources/xhr.js?v=git-18.201.27126-7bf0367 ����oO�àòÇXgØ.�ÁáÍXgØ.�Ú���HTTP/1.1 200�status:200�expires:Sun, 04 Nov 2018 06:41:57 GMT�date:Sun, 04 Nov 2018 06:41:57 GMT�cache-control:private, max-age=0, must-revalidate, no-transform�access-control-allow-credentials:true�access-control-allow-origin:https://drive.google.com�etag:"VWaTnJLJjz4....ccWINqWU/SI56113W.....KVlem4k38BY"�vary:Origin�vary:X-Origin�content-type:application/json; charset=UTF-8�content-encoding:gzip�access-control-expose-headers:Cache-Control,Content-Encoding,Content-Length,Content-Type,Date,ETag,Expires,Server,Vary,X-Google-GFE-Backend-Request-Cost�x-content-type-options:nosniff�x-frame-options:SAMEORIGIN�x-xss-protection:1; mode=block�content-length:995�server:GSE�alt-svc:quic=":443"; ma=2592000; v="44,43,39,35"��������Ë���0‚�Ç0‚�¯ ��������Ù$�ô`¬0 |
juanriccio:
Buffalo WBMR-HP-G300H
Lede SNAPSHOT r6953-aa30eb5 / LuCI Master (git-18.139.77294-37a4a1c)
To reproduce the problem, just log in and see how the starting page (Overview) has some sections hanging on "Collecting data...". For me, the affected sections are the following.
Network: both IPv4 WAN Status and IPv6 WAN Status (I'm not using IPv6 though)
Active Connections
DHCP Leases
DSL
Wireless
Associated Stations
Furthermore, the following fields in the System and Memory sections show no data (just a dash).
Local Time -
Uptime -
Load Average -
Memory Total Available -
Free -
Buffered -
I think this issue might have started with the new kernel. In r6664 there is no such issue, but it was already present in the latest r68xx I tried building. I'm sorry I didn't write down the exact release number.
The text was updated successfully, but these errors were encountered: