Timeout too short

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

Have a Nextcloud instance with a user with 30G of data + APCu + plugins: calendar, tasks, contacts and mail
Try to connect
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.

@mario

@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

@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

@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

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

@mario

@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

@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

@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

@grigi

@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

@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

@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.

@LukasReschke

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.

Navigation Menu

Repository navigation

Timeout too short #601

Actual behaviour

Expected behaviour

Steps to reproduce

Environment data

Logs

Web server error log

Nextcloud log (data/nextcloud.log)

20 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Timeout too short #601

Description

Actual behaviour

Expected behaviour

Steps to reproduce

Environment data

Logs

Web server error log

Nextcloud log (data/nextcloud.log)

Activity

AndyScherzinger commented on Jan 29, 2017

MightyCreak commented on Jan 29, 2017

AndyScherzinger commented on Jan 29, 2017

MightyCreak commented on Jan 29, 2017

tobiasKaminsky commented on Jan 30, 2017

MightyCreak commented on Jan 31, 2017

mario commented on Jan 31, 2017

MightyCreak commented on Jan 31, 2017

mario commented on Feb 1, 2017

mario commented on Feb 1, 2017

MightyCreak commented on Feb 2, 2017

MightyCreak commented on Feb 2, 2017

LEDfan commented on Feb 2, 2017

MightyCreak commented on Feb 2, 2017

ioguix commented on Feb 17, 2017

20 remaining items

asreimer commented on May 13, 2017

MightyCreak commented on May 13, 2017

JSoko commented on May 13, 2017

MightyCreak commented on May 13, 2017

MightyCreak commented on May 13, 2017

tobiasKaminsky commented on May 15, 2017

MightyCreak commented on May 15, 2017

tobiasKaminsky commented on May 16, 2017

dan-cristian commented on Sep 30, 2017

Jannis87 commented on Sep 30, 2017

sorcer1122 commented on Oct 6, 2017

MightyCreak commented on Oct 6, 2017

sorcer1122 commented on Oct 6, 2017

asreimer commented on Oct 23, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions