What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

How to allow multiple logins

AltF4

Occasional Visitor
I have attempted to login to my router from multiple computers, and it shows that I must log out in order to continue. I have to reboot my router to have it actually work.

Is there a place that I can set the # of users that can be logged in?
 
You can't. This is to prevent conflicts where two persons might be on the same page at the same time.
 
You can't. This is to prevent conflicts where two persons might be on the same page at the same time.

This is the first router I've have owned which experiences this :-(

Could we possibly get and option to enter our creds and disconnect other connected users before showing the main GUI?

BTW is this specific to the router's firmware, or your build?
 
Last edited:
This is the first router I've have owned which experiences this :-(

Could we possibly get and option to enter our creds and disconnect other connected users before showing the main GUI?

BTW is this specific to the router's firmware, or your build?

This is specific to Asuswrt. Not sure if Tomato also has the same limitation (Asuswrt was originally based on Tomato).

Allowing a webui option to force disconnect other users wouldn't be 100% safe. I can easily wipe out any trace of the fact that another user is logged in (it's just three nvram vars that need to be wiped out), but this can still lead to unforeseen consequences if there really is another person clicking at things on the webui on that other computer.

Without a thorough analysis of the internal handling of settings (I'm sure Asus did this for a specific reason), I'm not sure it would be a safe thing to do.

If you are positive that no one else is actively using the webui, you can flush the existing session this way:

Code:
nvram set login_ip_str=""
nvram set login_timestamp=""
nvram set login_ip=""
nvram commit
 
You're the man. Thank you. Yes it's just me. All other routers I have allow it. Never had an issue before. Thanks for all your help.

- Posted from phone -
 
This is specific to Asuswrt. Not sure if Tomato also has the same limitation (Asuswrt was originally based on Tomato).

Allowing a webui option to force disconnect other users wouldn't be 100% safe. I can easily wipe out any trace of the fact that another user is logged in (it's just three nvram vars that need to be wiped out), but this can still lead to unforeseen consequences if there really is another person clicking at things on the webui on that other computer.

Without a thorough analysis of the internal handling of settings (I'm sure Asus did this for a specific reason), I'm not sure it would be a safe thing to do.

If you are positive that no one else is actively using the webui, you can flush the existing session this way:

Code:
nvram set login_ip_str=""
nvram set login_timestamp=""
nvram set login_ip=""
nvram commit


I tried running these commands through telnet, but they did not work.
Doing "nvram show" displays that values still exist for those nvram vars :(
 
If the values are still set then it means either you didn't run the commands correctly, or you have a webpage open and still pointed at the router's webui.
 
If the values are still set then it means either you didn't run the commands correctly, or you have a webpage open and still pointed at the router's webui.

The webpage opened on the computer that has a telnet session connected?

I am definitely running these correctly, and in in a telnet console, but nothing appears to change (event when closing all browser windows)

Does it work for you?

I also tried:
nvram unset login_ip_str
nvram unset login_timestamp
nvram unset login_ip
nvram commit

which I saw you post in another thread. It just appears that my router wont commit it.
The attempts with telnet and SSH I have done from both LAN IP and WAN DDNS IP, and on different OSs: iOS 'Prompt' app, telenet windows, telnet OSX.

Also have tried spacing the commands out so the CrLf is accepted, or typing them in one by one. Still nothing :(
 
Last edited:
The webpage opened on the computer that has a telnet session connected?

I am definitely running these correctly, and in in a telnet console, but nothing appears to change (event when closing all browser windows)

Does it work for you?

I also tried:
nvram unset login_ip_str
nvram unset login_timestamp
nvram unset login_ip
nvram commit

which I saw you post in another thread. It just appears that my router wont commit it.
The attempts with telnet and SSH I have done from both LAN IP and WAN DDNS IP, and on different OSs: iOS 'Prompt' app, telenet windows, telnet OSX.

Also have tried spacing the commands out so the CrLf is accepted, or typing them in one by one. Still nothing :(

It works for me - I occasionally do it if I switched from wireless to wired with my laptop and forgot to first log out.
 
It works for me - I occasionally do it if I switched from wireless to wired with my laptop and forgot to first log out.

Good to know you do it also :P. But I would love to figure out why the hell I cannot change it from ANYWHERE. None of my variables are getting set. Any other possible causes that you could think of, or debugging techniques to try and figure out why the hell this could be?
 
It works for me - I occasionally do it if I switched from wireless to wired with my laptop and forgot to first log out.

More debugging leads to how this only *somtimes* works.
Appears more successful to use "unset" rather than "set" = "".

Appears that if you try to set or unset too many times (or possibly too man 'nvram commit' commands), then doing nvram get [var] shows that it will indeed NOT be set, until a reboot command is issued... wow.


Maybe I need to do an alternative approach.
Can I easily bring down and then restart the web interface?

I have been playing with "killall httpd", which works successfully.
But when trying to restart it via "httpd -p 80" I always get a 404 File Not Found when hitting the router again.

I looked into the code here, for httpd.c:
https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/httpd/httpd.c

Interesting that line 958 indeed sets those nvram vars... but if only nvram would ALWAYS respond to "sets" and "unsets" then this would work.

But on the httpd side of things, I was looking at the args needed to be passed in, and I guess I am not setting the correct ones to restart it?
Is it possible to restart it? If so, how?


EDIT:
I figured out how to basically "restart" the web interface now, but it still doesnt' allow me in from another computer because those nvram vars are still set and they refuse to unset NO MATTER WHAT!

The way to restart the web interface is:
killall httpd
service restart_httpd


But still doesn't help my problem :(
 
Last edited:
The httpd process isn't a "real" web server. It relies on nvram to determine if there is a live session at the moment.

Most common reason for an nvram commit to fail is if there is another commit being queued up. Another possibility which did happen to me a few weeks ago is nvram corruption. I was unable to set or reload any saved backup anymore, until I resetted back to factory defaults, reconfigured everything, then saved a fresh backup of my settings. Doubtful that it would also be your case (I do a lot more tinkering on nvram settings than you probably do ;) ) however.

The reason you couldn't just manually run httpd is because it looks in the current directory for its web content. That means if you were to put a modified copy of the /www content somewhere on a USB disk, you could change into that directory, and run httpd from there to have it serve this directory's content. But yeah, the proper way to restart the service is the way you did it.
 
The httpd process isn't a "real" web server. It relies on nvram to determine if there is a live session at the moment.

Most common reason for an nvram commit to fail is if there is another commit being queued up. Another possibility which did happen to me a few weeks ago is nvram corruption. I was unable to set or reload any saved backup anymore, until I resetted back to factory defaults, reconfigured everything, then saved a fresh backup of my settings. Doubtful that it would also be your case (I do a lot more tinkering on nvram settings than you probably do ;) ) however.

The reason you couldn't just manually run httpd is because it looks in the current directory for its web content. That means if you were to put a modified copy of the /www content somewhere on a USB disk, you could change into that directory, and run httpd from there to have it serve this directory's content. But yeah, the proper way to restart the service is the way you did it.

Should nvram get [var] instantly reflect the nvram set, or does it not take place until an nvram commit occurs?

It's honestly driving me mad. It looks as if my "sets" (or unsets) don't work what so ever!

I really would like to figure out why these variables are not getting set (cache or bug maybe?), but my only options left at this point are:
- just f-ing issue a "reboot" command
- beg you for an "Advanced" (w/ warning) setting to not have httpd set those 3 nvram vars. :P

Even after reboots now, it continues to screw over any change I am making. (did I foobar it?). It worked maybe once or twice before, but now not at all. Can I test for possible nvram corruption?
 
Last edited:
Should nvram get [var] instantly reflect the nvram set, or does it not take place until an nvram commit occurs?

I'm not 100% sure, but I believe it only takes place after a commit. I'm not sure because I always issued a commit after changing a group of values.

It's honestly driving me mad. It looks as if my "sets" (or unsets) don't work what so ever!

Just in case your issue is with the telnet/ssh client you are using - try doing these over the Tools -> Run Cmd page instead, see if you get better luck.

Even after reboots now, it continues to screw over any change I am making. (did I foobar it?). It worked maybe once or twice before, but now not at all.

At this point you might want to consider wiping your settings, and reconfiguring everything from scratch just to be sure your nvram partition isn't corrupted.
 
I'm not 100% sure, but I believe it only takes place after a commit. I'm not sure because I always issued a commit after changing a group of values.



Just in case your issue is with the telnet/ssh client you are using - try doing these over the Tools -> Run Cmd page instead, see if you get better luck.



At this point you might want to consider wiping your settings, and reconfiguring everything from scratch just to be sure your nvram partition isn't corrupted.


Yea, I tried it too :(.
Damn I changed a lot. I guess it would be worth a shot. I wonder if I can test for the corruption somehow.

EDIT:
I tried changing this, and the changes are indeed updated instantly: (so it only appears to be those damn settings that wont change! ... login_timestamp, etc)
nvram set vpn_server1_port="2000"
nvram get vpn_server1_port


EDIT 2:
Yep something is messed up. It now is like a permanent entry. Even after rebooting the router it is still mapped to this computer's IP address. Before it was "reset". So I guess I messed up that part of my nvram! (DARN IT!)

What are the steps required to gain a fresh nvram? Reset button?



EDIT 3: <--- FIXED
- I pressed the reset button
- Loaded from a settings backup that I did before messing with the nvram
- Now works perfectly, even when not doing an nvram commit.


For the sake of not messing up my nvram again, could you PLEASE (:D) add an option to disable the multiple user check. Just a simple setting in Administration, which sets a flag, which prevents the check in httpd. :D.
I would really love that
 
Last edited:
For the sake of not messing up my nvram again, could you PLEASE (:D) add an option to disable the multiple user check. Just a simple setting in Administration, which sets a flag, which prevents the check in httpd. :D.
I would really love that

Not gonna do it, because then I will get support requests about how concurrent logins are messing up people's settings. But I'll consider adding an option to force logging out any existing session, from the notification page.
 
Not gonna do it, because then I will get support requests about how concurrent logins are messing up people's settings. But I'll consider adding an option to force logging out any existing session, from the notification page.

Please do. That would solve the problem perfectly.
Now, even though I got it working, I am tempted to simply issue a reboot command, wait for my network to come back up, and deal with waiting :P (nvram corruption is a scary thought now that I experienced a little bit of its effect).

That simple setting on the notification page would indeed be perfect :D



Also, if I didn't thank you enough for all your help, time, and support before... THANK YOU. You are the man, and I really appreciate that you revamped this router to be such a better tool. I look forward to even more features / improvements in the future. The code is well written BTW :).
 
Not gonna do it, because then I will get support requests about how concurrent logins are messing up people's settings. But I'll consider adding an option to force logging out any existing session, from the notification page.

+1 for this feature too please Merlin.
 
The option to force an existing session to be logged out isn't doable without a LOT of work. Inactive sessions expire after 60 seconds, so just wait a minute and you should regain access to the router.

Concurrent logins won't be happening. If Asus specifically prevented these, then there must be a good reason. The backend was most likely never designed to handle multiple sessions.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top