Android: Timeout too short

Created on 29 Jan 2017  Â·  49Comments  Â·  Source: nextcloud/android

Actual behaviour

  • I can't connect to my Nextcloud server with the Android app because of a timeout

Expected behaviour

  • I should be able to connect, my instance is slow for unknown reasons (investigations in progress), but I can connect to it using either the desktop or the web client because the timeout is longer.

Steps to reproduce

  1. Have a Nextcloud instance with a user with 30G of data + APCu + plugins: calendar, tasks, contacts and mail
  2. Try to connect
  3. Doesn't work

Edit: Sometimes, with a bit of luck, it's possible to connect (1 out of 20 tries)

Environment data

Android version: 6.0.1

Device model: Nexus 5

Stock or customized system: stock

Nextcloud app version: 1.4.1 (F-Droid)

Nextcloud server version: 11.0.1

Logs

Web server error log

Nothing is added to the nginx log when I try to connect.

Nextcloud log (data/nextcloud.log)

Nothing is added to the nextcloud log when I try to connect.

Most helpful comment

Probably it should be possible to access and delete rows in oc_bruteforce_attempts as admin in the WEB GUI.

All 49 comments

@mario @tobiasKaminsky what do you think, afaik the timeout is 10 seconds at the moment. We could raise this though. Does anyone know the timeout value of the other clients?

On the web client, it takes up to 30 seconds to connect.

On a different subject, I honestly think there's a connection problem with the Nextcloud server, at least with 11.0.1, since my server isn't the most powerful, but it's not that bad:

  • 4 cores, Intel(R) Atom(TM) CPU N2800 @ 1.86GHz
  • 4 GB RAM
  • no important other stuff on it (a few static websites and a few crons a day)

Could you have some nginx/redirecting issue? Firewalling?

It's plain nginx, no redirection.

But it's Debian 8.7 which doesn't have PHP 7 yet :(

30seconds is way too long.
I suggest to ask in forum/ server-github/irc for some help to get this faster.
My v-server has much less power and is connecting < 1 sec.
Extending the timeout is not a solution but would just "hide" the real cause of the problem.
(if the first connection will take 30s, every following new connection will maybe also take this time, rendering the app unusable)

I agree. But I don't see what's the problem with my installation, it's almost vanilla. I tried to post a message on the helpdesk, but the answers aren't very useful.

Anyway I think the timeout in the android app is something like 5 sec today, maybe it's possible to crank it up a bit. It won't change the UX on instances that don't have my problem, but it will improve my situation.

Also, once I connect once on the web, the successive connections are very fast, until I close my browser (of course, I've cleared my cache and removed my cookies).

@MightyCreak what's the memory limit you have set for PHP? Also nginx timeouts?

Post config of both php and nginx please.

Also, please post output of iptables -L.

@mario it's all very common I think: memory_limit = 128M
But I don't know what are nginx timeouts though :S

And I don't have anything in iptables.

Edit: the framabin service will go down at 8AM UTC for a few hours, tell me if it's a problem for you, I'll drop the texts in another bin.

Just as a test, can you try to disable the bruteforce protection and let me know if that helps?

'auth.bruteforce.protection.enabled' => false,

@AndyScherzinger I would avoid raising timeouts - that does not solve a problem.

@mario nope, it doesn't fix the problem with the new line in the config file.

Edit: deleted lines, not the right bug

There seems to be a problem with Nextcloud 11 (nextcloud/server#3134). We'll see if the bug happens on more and more instances as Nextcloud 11 spreads out.

Edit: And here as well: nextcloud/server#2272

I would advice to increase the connection timeout in the Android app since it seems that HTTP/2 is not completely there yet (I don't have it because I had the bad idea to install Debian stable, I don't even have PHP7 :( ). If you don't want users complaining about the Android app not working, maybe it would be good to increase the timeout value until the problem is fixed on the nextcloud/server project.

@MightyCreak the problem described in nextcloud/server#2272 is caused by loading CSS and JS files, and I'm almost sure this can't cause timeouts in the Android app (since it doesn't use CSS or JS files)

You can test the performance of the PHP request with curl: (http://www.shellhacks.com/en/Check-a-Website-Response-Time-from-the-Linux-Command-Line)

    $  curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null NEXTCLOUD_URL

This is the result on my instance:

Lookup time:    0.004
Connect time:   0.032
PreXfer time:   0.093
StartXfer time: 0.222

Total time: 0.222

@LEDfan My problem isn't the connection to the server (which is indeed quite fast), but the connection of a user to its Nextcloud account (i.e. what happens once you clicked on the button "Connect" -- it's different in French, but I guess the button should look like that).

Same problem here with the android app.

My servers answers quickly, but the app is not able to authenticate:
~~~
Lookup time: 0,125
Connect time: 0,126
PreXfer time: 0,139
StartXfer time: 0,241

Total time: 0,241
~~~

Ok, I found that the root cause was the bruteforce parameter. I cleaned the database entries then everything went back to normal.

Same problem here with the app. Timeout when trying to connect with an user.
For me the solution was to connect with mobile internet the first time. But perhaps it was just luck.

If it's a real timeout, and not the bruteforce thing, will be fixed in 1.4.2

Hi all

I have timeout allways with the android app trying to connect the server. (raspberry PI with USB drive for data)

I have an old owncloud (old sempron w 1GB RAM) 8.x version, under the same router, and the APP work ultra fast.

I'm ussing the same no-ip dns service for both servers.

Any idea?

Regards

PAco

the timeout issue is "new" for me - probably after update from server 10.0.2 to 11.0.2 which I did this weekend.
android version is 1.4.2
ping from Indian ocean. - everything is a bit slow here.

icmp_seq=2 ttl=52 time=353 ms
icmp_seq=3 ttl=52 time=305 ms

@ferdiga brute force protection maybe? :-/

curl -s -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -o /dev/null NEXTCLOUD_URL

returns

Lookup time: 0,004
Connect time: 0,306
PreXfer time: 2,698
StartXfer time: 2,967

Total time: 2,967

login via linux /ubuntu 16.04 web browser - chromium - takes ~ 35 seconds
android after 10 seconds "The server took too long to respond"

regardless how brute force protection is set

@ferdiga which version of the Android client are you using? 1.4.1? Just asking since 1.4.1 has a 10sec timeout while 1.4.2 has 50sec!

I have 1.4.2 (and restarted the device to be sure) , but the timeout is 10 sec and no connection
the "secure connection" is established in 2-3 sec. but the login fails.

it seems to be a wifi problem, connection via mobile phone connection works
see also
https://help.nextcloud.com/t/android-app-can-not-connect-with-the-nextcloud-server-in-the-wlan/2626/31

@ferdiga

it seems to be a wifi problem

  1. If you have ipv6 enabled in your Network, just switch it of.
  2. Have a look in the bruteforcetable in your database

@JSoko
ad 1. can not switch it off
1.1 android needs to be rooted
1.2 no access to router or router not configurable

ad 2. some 300 lines -
"auth.bruteforce.protection.enabled": false

what else could I do?

BTW I can connect to the hot spot of another mobile phone and login to nextcloud
the connection shows both ip4 and ip6 adresses

Ad 2. Check if there is the ip of your phone in the local network. Delete those entries...

thanks
deleting the lines in oc_bruteforce_attempts solved the problem

Probably it should be possible to access and delete rows in oc_bruteforce_attempts as admin in the WEB GUI.

Yes, that was mentioned, but is OT here...

On a mobile connection, there could be a delay for various reasons. Even if it is a bug with the bruteforce protection… please consider increasing the timeout to at least 30 secs! Thank you!

(PS: I can confirm that once I changed my IP, the login succeeded after it always failed before. Something seems broken with the bruteforce mechanism.)

@dragetd see @mario's comment https://github.com/nextcloud/android/issues/601#issuecomment-282646954 if it is a simple timeout issue then 1.4.2 won't timeout anymore but if you get blocked by the server side brute force mechanism/blacklist than we can do anything about being blocked...

I am using 1.4.2, and get a timeout after 5 seconds. Looking at the logs, it takes ~12s to return a 200 OK.
I'm running this on a RPi on the LAN with a self-signed cert.
Brute-force is disabled (it made no difference).

Just wanted to comment here saying that I encountered this same issue on the Android client.

This issue was fixed by deleting rows from the oc_bruteforce_attempts table in the nextcloud database.

Cheers!

@grigi, I am also running this on an RPi on my local LAN.

Try increasing the timeout in your apache or nginx server config on the Pi. For me, the apache timeout was default 5 seconds.

I just install LineageOS on my phone and re-experienced the timeout issue.
I've tried 5, maybe 6 times, on Wi-Fi without success. As soon as I tried on the phone network, it worked instantly.

I don't see the obvious link here, but I wanted to share this experience.

@MightyCreak
Check if there is the ip of your phone in the local network in the bruteforcetable. Delete those entries...

I have some entries (with my uid) but it's not the same IP: starts with 192. in oc_bruteforce_attempts while my current IP on the Wi-Fi starts with 72..

But my IP may have changed until last time I was trying.

What is this bruteforce table anyway? seems like the cache of the browsers where the most common solution is "clean your cache" :D

Edit: wait... just saw I had 900 entries in this table and not only 25!!

Edit 2: nope, no mention of IPs starting with 72.. Maybe my IP changed, IP starting with 192. does ring a bell somehow

I've removed all the entries in that table (which might be part of the reason NC is so slow EVERYWHERE).

As soon as I launched the Android app, my IP was stored in that table... I don't understand what the rules are for bruteforce detection. If simply using the app is considered a bruteforce attempt, that's going to be hard to maintain this table.

Anyway, I asked the question on help: https://help.nextcloud.com/t/whats-the-rules-of-the-bruteforce-detection/12555

@MightyCreak you have some else apps that try to access the nextcloud server, e.g. Davdroid?

Yep, apparently it was my GNOME Online Account that was still connecting using my old ownCloud credential. Someone answered me on nextcloud help, so now I know that it's a connection failure that triggers an entry in the bruteforce attempts table.

So I would say that this issue is closed, but Nextcloud "core" needs to do something about the bruteforce attempts table that keeps growing up and slowing down the whole app.

Also, it's weird that when deactivating bruteforce detection, I still can't connect if the IP is in the bruteforce attempts table. Right now, if you want to disable bruteforce detection, you need to disable it in the config file and clear the table.

As far as I understood:

  • the bruteforce is only limiting the very first login, if you have logged in and then e.g. download a file it should be as farst as always
  • a specific ip remains for 24 hours in bruteforce table, but if your gnome online account uses wrong credentials you will be blocked immediately after 24h / ip change.
    @LukasReschke

(I cc to the server master guy and will close this, but we can of course discuss the bruteforce behaviour and in #893 we want to provide a proper fix)

I have the same issue with my android app. I disabled brute force protection on my 12.0.2 install and it works fine now.
After logging in first time I have enabled again the brute force check. The app works very very slow, so I had to disable it again.

i have the same issue on some of my android devices.
turns out that this was a problem with my ipv6 config. There was an unused AAAA pointer for my nextcloud domain with an ipv6 pointer leading to a wrong adress.
Some android devices seem to insist on ipv6 when they see an AAAA entry and dont fall back to ipv4.

My iOS devices are also configured to use ipv6, but they seemed to switch to ipv4 when something is not working with v6...

Having the same problem as well. Funnily enough, had bruteforce enabled and no problems. A few days ago I had to reinstall everything and now with 'auth.bruteforce.protection.enabled' => true in config.php I am not able to login, always give a timeout error on Android. Tried iOS as well - very very slow but at least I can login...

After I turned bruteforce off, everything works like a charm!

Bruteforce is pretty useful though. I also fixed my problem, at first, by disabling the bruteforce option, but I figured later that I still had GNOME Online Accounts that was trying to connect but with the wrong credentials. That was what was messing up the bruteforce attempts detection. (Basically that's how bruteforce detection works: if too many failed connections with same IP, then block the IP).

Check out the logs (I don't remember where they are exactly) for failed connection attempts and from which application. Maybe you'll find your culprit.

Also you'll have to flush the bruteforce DB otherwise your IP will always be blocked.

Yeah, I cleaned my DB already but left bruteforce off for now. Instead, I use fail2ban, which can block a bruteforce attempt for x hours/days/months and it does not clog up the DB.

YES. Use fail2ban instead. IMO, nextcloud doesn't need bruteforce protection because there is already much better software out there that protects against this.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AndyScherzinger picture AndyScherzinger  Â·  3Comments

JSoko picture JSoko  Â·  3Comments

tobiasKaminsky picture tobiasKaminsky  Â·  3Comments

tobiasKaminsky picture tobiasKaminsky  Â·  3Comments

JSoko picture JSoko  Â·  3Comments