Connection fails if ipv6 connection do not work properly

zolokonst commented 3 years ago

Steps to reproduce

Use ipv6-ready connection for both client and server.
Simulate the ipv6 connection failure on router, so dns name of your server should be resolved on a client. But server should not be reachable by resolved ipv6 address. IPv4 connection should work fine.
Go to login page in the android app and try to log in to your server. You'll see server error. If you already logged in, just try to upload something. You'll see the same error.

Expected behaviour

App should use working ipv4 connection, if ipv6 fails.

Actual behaviour

app doesnt communicate properly with the server.

Can you reproduce this problem on https://try.nextcloud.com

Yes

Environment data

Android version: 7.1.1 Device model: Sony Xperia performance x F8132 Stock or customized system: Stock Nextcloud app version: 3.4.2 Nextcloud server version: Don't care Reverse proxy: No

Logs

Web server error log

Insert your webserver log here

Nextcloud log (data/nextcloud.log)

I don't see the log file in the data folder.

zolokonst commented 3 years ago

I found this after updating app to the latest version. Ipv6 of my ISP isn't stable, but there was no such problem on a previous installed app version. Unfortunately, I can not say, which version was installed before updating.

KopfKrieg commented 3 years ago

I found this after updating app to the latest version. Ipv6 of my ICP isn't stable, but there was no such problem on a previous installed app version.

Same situation here. I can confirm that version 3.15.0 RC1 and 3.14.2 RC? both have this issue.

Using my instance's webinterface on the same device however works fine, so it's an issue with the app.

Carsten1987 commented 3 years ago

I have the same problem. Connect via Nextcloud-App is not possible. But Connect with Nextcloud-Talk is working! Android 9 Kernel: 4.4.11

Carsten1987 commented 3 years ago

Did an additional test and Downloaded 3.13.1 from GitHub. With this Version Connect works fine!

tobiasKaminsky commented 3 years ago

If IPv6 is available app uses it. So please configure your server correctly to work with v6 or disable it at all. The app cannot try v6 and then use v4 for every new connection.

KopfKrieg commented 3 years ago

The app cannot try v6 and then use v4 for every new connection.

Please reopen the issue. IPv4/6 fallback in case the other address is not working is a common standard, the software should be able to handle it.

zolokonst commented 3 years ago

The app cannot try v6 and then use v4 for every new connection.

Please reopen the issue. IPv4/6 fallback in case the other address is not working is a common standard, the software should be able to handle it.

Especially if it worked in previous versions.

tobiasKaminsky commented 3 years ago

Especially if it worked in previous versions.

It worked in previous version as there v4 was preferred, and only if no v4 was available it tried v6.

tobiasKaminsky commented 3 years ago

IPv4/6 fallback in case the other address is not working is a common standard, the software should be able to handle it.

What is your suggestion? Have app trying v6 on each connection, failing, then trying v4? This doubles the amount of connections for every request.

If you have a good way, we can surely discuss and implement this.

KopfKrieg commented 3 years ago

What is your suggestion? Have app trying v6 on each connection, failing, then trying v4?

If the DNS record returns both an IPv6 and IPv4 address then I'd first try the IPv6 address. If the request fails try the IPv4 address.

Maybe the result can be cached (which should also depend on the DNS lifetime) so we don't have to do this on every request (but only every 24 hours or so).

Using a single connection that is kept alive for multiple requests might also help.

If you have a good way, we can surely discuss and implement this.

I'm not sure how browsers usually handle cases like this, I hope it's similar to what I've mentioned above.

Right now I would just like to keep the issue open, and discuss how this could be implemented, even if we don't find the perfect solution.

EDIT: The other option would be to prefer IPv4 if both are available. It's sad, but IPv6 is still a lot more trouble than IPv4.

Carsten1987 commented 3 years ago

How does the Windows-App Manage this behavior? Or is it handled by OS?

zolokonst commented 3 years ago

What is your suggestion? Have app trying v6 on each connection, failing, then trying v4?`

I am not a developer. But in my mind @KopfKrieg provided good solution. May be some RFC describes this situation. If I want to do it simpler i'd tryed the next approach :

if (createConnection(..).status==CONN_TIMEOUT) {
    SessionProtocol.switch(next) ;
    if (createConnection(..).status==CONN_TIMEOUT) {
        ErrorHandler(CONN_TIMEOUT);
    } 
}

It doubles timeout if connection lost. But if any of two protocols are available, connection establishes. If it difficult to implement SessionProtocol entity, it might be changed to already realized (as I can understand) PreferredProtocol.

github-actions[bot] commented 3 years ago

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

zolokonst commented 3 years ago

Up

github-actions[bot] commented 3 years ago

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

KopfKrieg commented 3 years ago

Bad bot. The issue is still relevant.

github-actions[bot] commented 3 years ago

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

Carsten1987 commented 3 years ago

Bad bot. The issue is still relevant.

laf0rge commented 3 years ago

I can confirm this issue is happening still with today's version of the nextcloud android app from the play store. It's 100% reproducible.

The standard behavior of any client program with IPv6 support (as it has always been for the past 20 or so years as far as I recall) is to first try IPv6, and if that fails, fall back to IPv4. This works with any other software that I know of, whether on Linux, proprietary desktop OSs, or on Android.

The nextcloud android client is the only program I have ever seen exhibiting this bug. Using IPv6 since the late 90ies I would think I am qualified to make such a statement.

I know close to nothing about Android APIs, but on the C library level on Linux you are using getnameinfo() to get all the DNS records for one given host name. And then you iteratve over those, trying to establish a connection to each of them.

If you fail to do so and only try the first, this will create problems

with IPv4 fallback if IPv6 DNS records exist
with the common usage pattern of using round-robin DNS (multiple A records for one hostname) to distribute load among multiple servers.

laf0rge commented 3 years ago

https://eng.libretexts.org/Bookshelves/Computer_Science/Book%3A_An_Introduction_to_Computer_Networks_(Dordal)/08%3A_IP_version_6/8.12%3A_Using_IPv6_and_IPv4_Together looks like a good basic text on the subject.

It also links to RFC 6724 (preferences of priority/ordering handled at OS/DNS level) and the optional alternative of RFC 8305 "happy eyeballs" of doing this more concurrently and less sequentially.

laf0rge commented 3 years ago

If IPv6 is available app uses it. So please configure your server correctly to work with v6 or disable it at all.

You are completely missing the point. The server may very well have excellent and reliable IPv6 connectivity. But then, you cannot control in which netwokrs a client, particularly a mobile client is roaming around

you might be connected to some hotspot that is either misconfigured or has a [temporary] IPv6 routing problem
any intermediaten transit network might fail for IPv6 but not for IPv4

Those things happen all the time, everywere.

The app cannot try v6 and then use v4 for every new connection.

Any other application (like all web browsers, for that matter) can, but the nextcloud client application cannot? To iterate some Android examples that work as expected in this scenario by doing proper v4 fallback: k9mail, Xabber, DAVx5, all Google apps, Amazon, Bandcamp, Chrome, DB Navigator, DB Tickets, eBay, F-Droid, Fennec, Jitsi meet, Mixcloud, NewPipe, Oeffi, OsmAnd (map downloads), Prime Video, Signal, Soundcloud, Speedtest, VLC, ...

btw, it seems that this issue already existed as early as 2014 (#616)

Alex98234 commented 3 years ago

I think #7400 is the same issue.

mepreston commented 3 years ago

I'm piling on. the function works just fine in 3.13.1 which all my android devices are running because my ISP is crap and up grading to any newer version breaks connecting to my nextcloud server. as mention in prior post, this app is the only one on my devices that will not fallback to ipv4 if ipv6 isn't working. I don't get why it is taking so long to put the code back in that took care of this, it isn't like you are adding a new feature, you removed it when it was already there and working fine.

AndyScherzinger commented 3 years ago

I don't get why it is taking so long to put the code back in that took care of this, it isn't like you are adding a new feature, you removed it when it was already there and working fine.

There was no code that took care and has been removed. The behavior changed from ipv4 with fallback to ipv6 which in an case the fallback only ever got triggered if no config had been present. So if ipv6 config is present but doesn't work than there is no ipv4 fallback. Same now if there is a ipv6 config provided via your DNS than it is used, if it doesn't work then there is no fallback, if DNS only provides ipv4 than that will be used (since ipv6 isn't present).

Alex98234 commented 3 years ago

A third issue - #7907 - which I think is the same thing.

github-actions[bot] commented 3 years ago

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

sndrr commented 3 years ago

My workaround is to set distinct IP versions in DNS and use the IPv4-version:

cloud.4.example.com for IPv4
cloud.6.example.com for IPv6
cloud.example.com for both IPv4 and IPv6 (this one fails)

mepreston commented 3 years ago

i'm very disappointed with nextcloud development that they can't fix this to work like firefox and chrome browsers to fall back from IPv6 to IPv4 when there is an issue connecting. i guess long time i'll only be using firefox on my device and remove the nextcloud client from my phone it doesn't seem that this will ever be addressed. My ISP still isn't consistently working with IPv6.

mm28ajos commented 3 years ago

IPv4/6 fallback in case the other address is not working is a common standard, the software should be able to handle it.

What is your suggestion? Have app trying v6 on each connection, failing, then trying v4? This doubles the amount of connections for every request.

If you have a good way, we can surely discuss and implement this.

Any update on the dicussion @tobiasKaminsky ?

Alex98234 commented 3 years ago

So far the only way to mitigate this issue was to remove the domain AAAA record entirely. With only a A record, only a IPv4 adress is available the the connection does not fail all the time.

2021 and I have to disable IPv6, this is strange.

mm28ajos commented 3 years ago

Indeed. The point is, that the behaviour can be triggered client side and not only server side issues. Had some users which turned out to have been connected to ipv6 routers for which ipv6 routing was from time to time not working and now they experience this issue.

mepreston commented 3 years ago

seriously firefox mobile has never had an issue connecting my nextcloud server but this client does. if they can do it why can't you?

hofinger82 commented 3 years ago

Any news here? The app is not usable with this bug.

mepreston commented 2 years ago

this should not have been closed as this is still an issue. I'm very disappointed that this app can't deal with ipv4/6 like other apps do.

mepreston commented 2 years ago

can someone reopen this or point to a current open bug on this issue?

laf0rge commented 2 years ago

@tobiasKaminsky pleaes kindly re-open this issue. It is a real issue. Virtually any client application on this planet gets this right, just nextcloud is continuously refusing to fix an obvious bug in handling network scenarios where the IPv6 route is temporarily or permanently interrupted, while IPv4 is availalbe and works.

laf0rge commented 2 years ago

For the record: I have had to remove the AAAA record of my nextcloud instance (server side) just to make the constant complaints frm users with flaky IPv6 routing go away.

So basically, by closing this bug, the developers are saying: Either you use IPv5, or you use our android client. But you cannot really have both [in a reliable way, with the proper fall-back]

mepreston commented 2 years ago

it seems there are more than a few unhappy users of this app for other reasons besides this issues.
https://www.reddit.com/r/NextCloud/comments/q6obpb/alternative_android_clients/ I guess i should also look at replacing this app with something else since on one wants to improve or fix issues with this app. your giving NC server a black eye.

tobiasKaminsky commented 2 years ago

We will discuss it next week.

mepreston commented 2 years ago

these three issues all seem to be related. prefer IPV6 addresses if available #503 ipv6 not reachable, app not fallback ipv4 #7400 Connection fails if ipv6 connection do not work properly #7839

The two open "bug" have been opened more than an year and yet this issue still have not been resolved. Is anyone doing project management for this product? this is giving NC server a black eye when the mobile client can't connect . https://github.com/nextcloud/android/issues/7400 https://github.com/nextcloud/android/issues/7839

AlvaroBrey commented 2 years ago

Closing in favor of #7400 to not have a duplicate issue. All subsequent discussion will be had there.

AlvaroBrey commented 2 years ago

For people subscribed to this issue: Can anyone test this APK https://github.com/nextcloud/android/issues/7400#issuecomment-1011913182 and see if it works under the circumstances described in this issue? Please direct all further feedback to #7400 to avoid duplicating conversations.

nextcloud / android