Admin won't stay logged in for more than a dozen seconds

> That whiner comment was totally uncalled for.

      https://www.google.com/search?q=sarcasm+wasted

> 1 Kudo

   _That_ was predictable.

Fair enough.
It is hard to tell sarcasm from intention based upon text messages though, unless you happen to know the person well.

You could presume that my response was also sarcastic...  

But no, not true, I got it wrong there. Oops. My mistake there.

Anyway, after a week or so of greatly improved behavior, I would take a fairly reasonable guess that the underlying admin timeout issue has a fundamental flaw or bug in it. This would be behind many of the other threads related to this issue. The fixes in those cases were more likely to be happen-stances that avoided running into the real bug. 

Today for example, someone reported that the printer was inaccessible. I got into the router and found that I was getting about 5-6 clicks before logging me out. So it seemed to have regressed a bit. It was better than before when 2-3 clicks was the norm, so that was a little more workable. A few days earlier, it seemed there wasn't a limit. 

What I also found was that the printer was listed as on-line, but without an IP address. Checked if we had run out of them (dhcp), no. Power cycled the printer, and it came back on line. Oddly, it was still listed as online even when it powered down, and everything refreshed in the router. Who originally created the problem isn't my issue (who knows). It seems that one apparently-unrelated problem triggers and/or exposes another.

The problem is that the admin should stay logged in long enough to find out where the problem might be.

Richard.

And today, the problem is back again. Absolutely nothing has changed since it was last working. 

Need to add another machine to the network, but the thing is logging me out before I can get there. What the heck is wrong with this thing? What basic bit of logic is in there that doesn't allow a session to exist for more than a handful of seconds?

It was a dumb idea to route all the logins this way in the first place -- a technology that Netgear have not either thought through or executed properly. Avoid ! as it doesn't seem they will either correctly identify or fix the issue

---

richard42ack wrote:

And today, the problem is back again. Absolutely nothing has changed since it was last working. 

 

---

This may sound like an odd one, but I recently had a problem on an R7800 that I fixed by disabling:

Always Use HTTPS to Access Router

Buried in Web Services Management, it seemed to get in the way of using a browser alongside an app to access the router.

That setting was probably a response to requests for more secure access to the graphical user interface. As implemented it seems to upset things.

It may or may not have anything to do with what you see, but it might be worth trying.

Thanks for the suggestion. It seems that it may make sense in that this appears to be a token issuing problem. Such things are time sensitive, and my thought is that there is some clock skew/drift going on. The apparent flaw in the design is that once a token is obtained, it should be valid for a reasonable period without being re-checked. Whatever they are doing seems to be resulting in incorrect attempts to obtain new and unncessary tokens.

My thought is that the clocks have drifted somewhere (even though they are supposed to be all sync'd) and that is a factor. 

I haven't found anything suggesting mine was having some https issue, at this point. But I appreciate the suggestion. 

One brute force approach would be to disconnect it from the internet and thus deny it the means to try to do sso over the internet. However, all users would then also be kicked out, unless I can figure out a more selective means of doing it. In the meantime, I have added another router to the network and added the device there instead.

Thanks,

Richard.

Another thought, there is a discussion under way on the "Idea Exchange" section. It does not quite fit in with your problem, with a very short interval, but it is along the same lines.

Admin Timeout - NETGEAR Communities

wrt very short timeout link posted: Yep, it was always bad in that regard too.

Did they really mean it to be so short, or did it get messed up in some fundamental way that caused both of the problems? My guess is the latter. The timeout was always so ridiculously short that it is difficult to believe that anyone would have deliberately made it that way.

Richard.

Latest update in here is that the solution to the problem is...

Turn mu-mimo off.

Richard.

Well, not quite. There were 2 things that were done, and it seems undoing either of them brings the problem back again. The first is to disable mu-mimo, as noted previously, the other is to enable access to wired ports. I don't know if there is any rhyme or reason to that. But once the immediate problem is addressed, the other problem that others have spoken of (very short sessions before logout) also seems to be solved. 

What I notice is that some requests, such as getting the current list of devices take many seconds to execute. It ought to be a simple local lookup, so not sure which scenic route it might be taking. Or what might be delaying it.

Richard.

I would perhaps contact NG support

https://www.netgear.com/support/#

or a forum moderator over in this more appropriate forum to express your experiences to:

You might get/find better information here:

      https://community.netgear.com/t5/x/bd-p/business-wireless-for-business