jow-:

Please provide the output of https://192.168.1.1/cgi-bin/luci/admin/status/overview?status=1

juanriccio:

Hello and thank you.
Here is the output, slightly edited to protect the innocent.
Apparently, the data are all there.

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:

TypeError: info is null[Learn More]
overview:107:8

https://router.lan/cgi-bin/luci/admin/status/overview:107:8
XHR/this.get/xhr.onreadystatechange
https://router.lan/luci-static/resources/xhr.js:75:5

(several times)

jow-:

In the network tab, can you please expand one of the ?status=1 requests and look at the response? Is it reporting status 200 OK? Do you see any security or network related error messages in the console, despite the TypeError messages? Also can you mention the exact version of Firefox? Do you access via HTTPS?

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)
Firefox SR 52.8.0 (x86 Windows)
Opera (several versions)
Chrome

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.
Here are the culprits.

107 var ifc = info.wan;

75 callback(xhr, json);


The error is always the same:

Paused on exception
TypeError: info is null
I'll be glad to perform more tests.

jow-:

Please try disabling the HTTPS enforcement in uhttpd and see if the same problem happens on plain HTTP connections.

uci set uhttpd.main.redirect_https=0
uci commit uhttpd
/etc/init.d/uhttpd restart

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 ...
that was not existing 2 weeks before

eg:
http://192.168.1.11/cgi-bin/luci/admin/network/wireless
there it doesn't show the connected wlan clients, which is important but not working :(
it shows only: "Collecting data..."
Model ZBT-WE826 (16M)
Architecture MediaTek MT7620A ver:2 eco:6
Firmware Version OpenWrt SNAPSHOT r7314-c4aadbd / LuCI Master (git-18.176.34901-0d9a64b)
Kernel Version 4.14.50

camel:

meanwhile tested also mt7621 device with current trunk ...
same issue:
Model ZBT-WG3526 (16M)
connected wireless clients should be 6 (as i can see that on luci statistics -> wireless -> connected devices

but no info on status page or on network->wireless overview.
also tested with autorefresh off, still not working.
also tried to increase xhr- poll timing to 30, but also no effect ..

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
confirmed .. is now working with that fix.
(currently not in trunk build, normal user need to wait till a new trunk build
(is in package: luci-mod-admin-full)

pls, ticket can be closed.

camel:

hmm ...
seems to be again :(
now the assosiated clients are visible, but the network and wireless view are not always displayed
seems to be, that on fast (good cpu) router it is working (eg: mt7621)
but on mt7620 it is mostly not visible, sometimes it visible for 5sec, and then again gone.

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) ?
can anyone take a look
OR MAYBE possible to increase the poll timing to give more time to get informations for the interface view scripts ?

camel:

i would recommend to increase the poll -> as there can be on much interfaces more time needed as "POLL 5sec"

see: file:
/usr/lib/lua/luci/view/admin_status/index.htm

line: 201

• XHR.poll(15, '<%=REQUEST_URI%>', { status: 1 },

• XHR.poll(15, '<%=REQUEST_URI%>', { status: 1 },
  function(x, info)
  {
  if (!(npoll++ % 5))
  updateHosts();

who can take care to change this on trunk ?
or better fix ?

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 <
There was also the following error in various other places, depending on the page:
network:89 Uncaught ReferenceError: XHR is not defined

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
� †H†÷
�����0T1�0 ��U����US1�0���U�
��Google Trust Services1%0#��U����Google Internet Authority G30��
181016113700Z�
190108113700Z0f1�0 ��U����US1�0���U��
California1�0���U��
Mountain View1�0���U�

Google LLC1�0���U��.google.com0Y0���†HÎ=����†HÎ=����B��-òŽ„7ú>Ï�Ú¿Ú
£ÝGÓp}ƒ�’�2€èÛÏx�³ª­�h�Á«-�–¥Ñèü>7
:3„�Ž�CöÒ=ma�ÌÇ£‚�T0‚�P0���U�%�0
��+�������0���U����ÿ�����€0‚����U���‚��0‚�‚.google.com‚
.android.com‚�.appengine.google.com‚�.cloud.google.com‚�*.g.co‚�*.gcp.gvt2.com‚
.ggpht.cn‚�.google-analytics.com‚�*.google.ca‚�*.google.cl‚�*.google.co.in‚�*.google.co.jp‚�*.google.co.uk‚�*.google.com.ar‚�*.google.com.au‚�*.google.com.br‚�*.google.com.co‚�*.google.com.mx‚�*.google.com.tr‚�*.google.com.vn‚�*.google.de‚�*.google.es‚�*.