[egosumumbravir]

Bit of an odd situation after an upgrade, has anyone encountered something like this before?

Did an in-place GUI upgrade of a Netgear R8000 from an older (r47822) to r50146 while keeping config.

It seems to have gone OK (most everything works) but there's a weird intermittent bug where the internal webpages won't load (latest Firefox) - click on a link and the browser stalls waiting. I can pretty much immediately click "stop" and "refresh" and the page will then load as normal. Usually stalls between the 5th to 10th link/page, so often enough to be annoying.

Current troubleshooting has been - factory reset the router: no resolution
- clear the firefox cache: no resolution
- the router responds to pings consistently through page stalls.

Since it's late and I'm beat, there's more to try tomorrow but I thought I might ask to see if anyone else has seen this kind of behaviour.

Tomorrow troubleshooting - test with chrome, then reflash r50146 with firmware reset. (or should I downgrade 1 ver and then upgrade??)
Is there a log somewhere I should be grepping?

cheers

edit: yes, I'm hardwired. No WiFi.

[Alozaros]

your best move: reset and manual reconfig...50146 is the last build you dont need an older..
also make sure you dont have addons that can case the issue...FFx is better than chrome as chrome based browsers are know to cause GUI troubles...

[the-joker]

Nothing new you report. Build threads ad naseaum hit the mark on what to do, we all made sure this info was covered.

Browser Cache clear is very important, CTRL+F5 to force clear it, the web interface then and now is like night and day, in fact most of the css no longer exists in the same way and quantity/repetition it use to. But Browsers will cache crap no matter if you tell them to or not, local stuff is grabbed and kept and later the old local crap will head butt the new stuff, and local always wins and if wrong you see what you see, perhaps even worst.

Sometimes reflashing helps somewhat, Ive noticed that for instance HTTPS side, when Im on my 3rd daily flash of newer dev builds, some slowness with authentication and back and forth browser server side, I often notice some things gets cleared up, like it sneezed and suddenly some crap got cleared up. My theory is at the nanometers of the flash sometimes electrons may just misbehave, this is a known issue nothing can solve and will only get worst as things shrink on the nanometer scale.

And there is a reason why most of the time nvram resets are recommended, some gremlins refuse to go away any other way.

The next public build should be slightly better, were now loading the JavaScript later and css first (random FOUC clearing technique), again cache clear will be important to out the gremlins holding to cached crap JavaScript side.

And also smaller, /etc/www (where everything ui is stored in a single file) use to be around 3.5MB perhaps more, then 3204261 bytes @Aug 14 and @r50167 2982974bytes Sep 14, after -r50173 2905386bytes Sep 14.
We have worked hard and removed almost all the old useless crud and optimized the themes and way it works together. Still I am already eyeing more useless stuff to remove and further make that number smaller.

Easily checked by doing ls -all /etc/www

[dale_gribble39]

The problem is a renewed failure to load the CSS that was not as prevalent for a while, but now it's back. Mostly related to browser cache as stated, but when it does it when the cache is clear and you just opened the browser and pointed it at the (default elegant style and anything tied to it, including the new themes), that seems to be something not seen for a while... and it matters not which browser you're using.

[MysticGold04]

I am getting the same exact thing on my RT-AC3100. It is randomly happening to me too. Multiple computers and browsers, both wired and wireless. Cache cleared with Ctrl-F5 multiple times.

I have dark styles enabled. it seems like the httpd daemon is dying. I can ssh in and issue the command:

[Phil9992]

@MysticGold04 So is it the same thing, since @egosumumbravir says stop and refresh works ?

@egosumumbravir It may be an inadequate station network configuration or antivirus related issue for instance. Could you please tell us what is your OS, what is your antivirus if any, are you using https, dd-wrt congestion control algorithm, and so on ?

[MysticGold04]

for me, clicking stop and refresh does nothing to bring it back. It successively times out if I do that. The only way to bring the UI back is to power off and reboot, or to ssh in and reboot or restart the httpd service.

[dale_gribble39]

A simple refresh of the page or CTRL+F5 reloads the page successfully in most instances, or should.

[egosumumbravir]

[kernel-panic69]

The only other possibility is that your power supply adapter is failing, barring no hardware failure. I don't have a tri-band router to test to see if it's specific to these particular Broadcom devices. I am not seeing it on the R7000P, and I *always* use a separate portable browser with no extensions or add-ons loaded in private browsing mode using only http.

I (we) have seen random garbled webUIs again when using anything that uses the elegant-based UI style, though - but haven't in 50176 yet. The kromo, xirian, brainslayer, wikar UI styles do not have those issues. But there's been even more patches submitted since 50146 and a couple since 50176. Quite honestly, I've been expecting the CSS loading issue, but I haven't seen the webUI httpd process come grinding to a halt.

[the-joker]

I can force this issue to present itself, by changing tabs in sequence and with intent to nothing else in any given page, eventually the router will choke and things will not load.

I have recently made a change to load JavaScript later and in some instances saved the browser some processing time rending the pages because they didnt have to be redrawn, other minor fixes to invalid tables, which prevents browser from reading the file and then try to fix the invalid table HTML layout.

Other possible causes can also be made worst with certain addons, ublock + and others should all be disabled DD-WRT side, there is nothing to protect against or anything to block and all these addons and their injected JavaScript can have unintended performance effects.

Hard to know, could be many things and Im sure none related to DD-WRT. Imagine if it were, we would be flooded with bug reports left right and center. None the least I would have noticed it as well. Can say that it is so, I hate under performing crap.

[kernel-panic69]

In my experience, uBlock is usually benign, but can be disabled as it's not required. I've tested with and without it enabled and haven't noticed any glaring difference. I've just ping-f*cked everything from WRT54* to R7000P on 50181M to try and get the httpd to choke or crash. It may happen in non-private non-incognito mode, but it doesn't happen in private / incognito mode - and I don't have any add-ons or extensions loaded and not accessing with the same browser I cruise the internet with. The only non-portable browsers I use by default have been Waterfox Classic and Firefox ESR/Quantum. This has been the case for quite some time on both official and personal builds when others have had crashes and other issues. It is *very* random that Elegant-based styles display the CSS load failure anomaly, but I don't expect it to go away completely. NOTE: The "M" has nothing to do with webUI/httpd save and except for offered packages - outside of those modifications, it's 100% upstream code. IOW, anything you or BrainSlayer has committed is in play.

[egosumumbravir]

[dale_gribble39]

It has always been random. No definite chronic specific circumstantial variables involved. I'm somewhat confident that maybe once all of the .css / webUI code tweaks are done, it may settle out. We'll see. <wink>

[the-joker]

Nothing todo with CSS/HTML Web interface wise. The elegant themes were refactored as they stand currently are less 75% CSS to do same job. Performance should increase and size of /etc/www has decreased steadily (it will increase eventually when some other designs are introduced like responsive or flexible designs, nothing has been decided or started to be worked on.

Try clearing browser cache with CTRL+F5 and dont hammer the tabs in sequence just to trigger issues, because in that scenario it will happen sooner or later.

The lead dev is aware of failure to load CSS randomly and even language.js that is a separate issue that has nothing todo with the web interface itself. Nothing has been done toward that end.

Last conversation around that subject it was said that sometimes the browsers sends and empty request, now if that is any cause wouldn't know. The HTTP server is custom built for speed and small size, so could be any unknown cause at this time.