Skip to content
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

hasRootPass timeout: unusual long access time for web interface #665

Open
Akira25 opened this Issue Feb 14, 2019 · 21 comments

Comments

Projects
None yet
4 participants
@Akira25
Copy link

Akira25 commented Feb 14, 2019

build: dev-daily-012a952 (2019-02-13) and dev-daily-1743bf7
device: tplink_c50-v4

Accessing frei.funk, LuCI needs very long to (initially) load. It can take from 35 second up to a whole minute. After the first page (frei.funk) was load, the other pages load at normal speed.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 14, 2019

I have created a branch called fix/hasRootPass which addresses this problem. I'm traveling now and will create a pull request when I am back on the 22nd. But if anyone else wants to make a pr for the branch in the meantime, feel welcome.

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 15, 2019

in your commit freifunk-berlin/firmware-packages@052a0a8 you are using luci.sys.user.getpasswd("root") which is not working.

logger(tostring(luci.sys.user.getpasswd("root")))

returns "nil" even when a password was set.
I'd choosen to add an additional CGI-script (freifunk-berlin/firmware-packages@fe76367), as this runs a root (who has access to the password-file), whereas the LuCI is running as an unpriviledged user.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 21, 2019

The cgi script is timing out where it is being called by LuCI. When I run the same wget command manually, it returns immediately. I suppose another way to fix this bug would be to get the wget call to work properly.

When it times out, the result is "password_is_set:no" which is not what https://github.com/freifunk-berlin/firmware-packages/blob/4ad95b8536653c6b4c61fc358ae6c778e4d6c92d/utils/luci-app-ffwizard-berlin/luasrc/tools/freifunk/assistent/tools.lua#L74 is checking for.


While coding freifunk-berlin/firmware-packages@052a0a8, I tested the call luci.sys.user.getpasswd("root") differently. I didn't convert it to a string. I don't have the test code anymore, but it should look something like this:

if not luci.sys.user.getpasswd("root") then
  logger("passwd not set")
else
  logger("passwd set")
end

I don't guarantee that I'm right about this. Also, I don't think I have the time to work on this the next couple of days. I'll write another comment when I know more. see #665 (comment)

@pmelange pmelange changed the title dev-daily: unusual long access time for web interface hasRootPass timeout: unusual long access time for web interface Feb 21, 2019

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 23, 2019

I just tested the call to luci.sys.user.getpasswd("root") as described in #665 (comment). The results are just as @SvenRoederer described. It doesn't matter if the password has been set or not, the result is always the message "passwd not set".

So, now we need to find out why the call to wget is timing out. Anyone have any ideas?

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 24, 2019

I tried changing the wget to /bin/wget and localhost to 127.0.0.1 and there was no change
When I run ps, I see the wget command, which simply times out causing our problem.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 24, 2019

After working on a few more issue, I have tried the fix/hasRootPass branch again. At the first boot, I get sent to the changePassword page. I put in a password, and it works fine. Afterwards I don't get confronted with the changePassword page again. Page loading is at the normal speed.

Edge case:
If I instead decide not to enter a password on the changePassword page, then after going through the wizard and rebooting, the normal freifunk page comes up. Many, but not all, of the pages in the interface show the built-in "No password set!" alarm box from OpenWrt. If anyone finds it important to have the alarm box in this case be shown on all pages, then please open a separate issue.

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 24, 2019

probably using luci.http can be used in place of calling wget. I used wget as I did not want to check for it's api (https://htmlpreview.github.io/?https://raw.githubusercontent.com/openwrt/luci/master/documentation/api/modules/luci.http.html)

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 24, 2019

I tried luci.sys.httpget and had the same results. Then I looked into the code, and it does a wget.

PR #181 works with the current 18.06.x master branches.

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 24, 2019

if I remember correctly, at least one of the problems fixed by the cgi-solution was:

  • not displaying the wizard-password page, when the root-account had a password set by other means already (e.g. via a preseed uci-default script)
@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 24, 2019

luci.sys.user.getpasswd("root")

see also #208

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 24, 2019

So, now we need to find out why the call to wget is timing out. Anyone have any ideas?

Any better idea than bisecting?

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Feb 24, 2019

Edge case 2:
Before loading the web interface, I logged via ssh and set a password. Then when loading the web interface I was confronted with a request for a password. The correct password doesn't seem to work and I was forwarded again to the same password request page. (see description of 8dc3728)
Solution:
Click on Administration at the bottom, log in, run the wizard from the menu.

This solution (with the two edge cases) is still better than the non-functioning cgi script.

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Feb 25, 2019

So we had a solution that was working. This solution broke by some change. Your solution has some known problems ...
So I suggest bisecting down to the point when it broke. there we will see what change and how to deal with that cause.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 2, 2019

The results of bisecting (my oh my that takes a long time) is that the bug was introduced in 2823ec3

Now, I suppose it's time to go though all the feeds and bisect those too. That will unfortunately take even more time.

But my concern is how 2823ec3 made it to the master branch. It was not in a PR, and I don't think it was ever tested. Isn't testing a prerequisite to pushing on the master branch?

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 2, 2019

I have finally found the root of the problem.

The commit on openwrt/master is openwrt/openwrt@c6aa9ff
the commit on openwrt/18.06 is openwrt/openwrt@e5a0b6c (cherry-picked from master).

The effect is that the uhttpd config setting max_requests has been reduced from 3 to 1 for performance reasons. But this causes the hasRootPass cgi-script to be blocked and it eventually times out.

There are potentially two solutions.

  • we override the setting ourselves.
  • we convince upstream that it is a bad idea to have max_requests set to 1 and have the commit reverted.

I will create a PR for solution 1 since solution 2 may take a while.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 2, 2019

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 2, 2019

PR freifunk-berlin/firmware-packages#183 has been created to solve this issue

@SvenRoederer

This comment has been minimized.

Copy link
Contributor

SvenRoederer commented Mar 2, 2019

What about changing the cgi-script into an rpc-function? This will not cause the problems we see here with cgi-scripts.

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 2, 2019

rpc needs authentication https://github.com/openwrt/luci/wiki/JsonRpcHowTo. In fact luci.sys.user.* functions are rpc functions and we know that they don't work.

I have spent far too much time on this because of a commit (2823ec3) which was never tested before being commit to the master branch.

If you have a better solution, please make a PR, get it peer reviewed, tested, and merged. Then feel free to close PR freifunk-berlin/firmware-packages#183

SvenRoederer added a commit to freifunk-berlin/firmware-packages that referenced this issue Mar 10, 2019

ffwizard: convert cgi-bin into rpcd-function
Upstream has changed the number of concorrent cgi-scripts running
by uhttp to 1, which causes a timout when the calling the "has_root-pass"
cgi-bin.
As the current cgi-bin version was initially a prove-of-concept it's
time to convert this into a RPCd-call.

This fixes freifunk-berlin/firmware#665
@everloop2

This comment has been minimized.

Copy link

everloop2 commented Mar 15, 2019

seems to be fixed at SAm0815, frei.funk and LuCI-login responds after 1-3 seconds

running on:
Modell: Speedport W 504V Typ A (1x333Mhz)
Architektur: Danube rev 1.5
Firmware Version: Freifunk Berlin Dev-SAm0815 11afd3d / LuCI feed_mk branch (git-19.063.78882-af73045)
Kernel Version: 4.14.105

@pmelange

This comment has been minimized.

Copy link
Contributor

pmelange commented Mar 19, 2019

The web interface may be loading faster, but the functionality of hasRootPass is not yet ready. Check out the comment in freifunk-berlin/firmware-packages@5facfff

I'm looking forward to seeing this work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.