Android net-detect on 4.2: False "Sleeping until network is available"

REPRODUCIBILITY (% or how often): 100%
BUILD ID = OS VERSION (Settings > About product): Verla, 4.2
HARDWARE (XA2, X10, X10 II, …): XA2
UI LANGUAGE: English
REGRESSION: (compared to previous public release: Yes, No, ?): Yes

DESCRIPTION:

Android Mail Client (k9) refuses to connect to internal server, because ipv4.jolla.com wasn’t reachable

PRECONDITIONS:

Enable Android support and install an Android MailUserAgent.
Configure Sailfish to get successful Wi-Fi connection with complete address setup

STEPS TO REPRODUCE:

  1. Make sure preconditions are met
  2. Start Android MUA

EXPECTED RESULT:

Android MUA connects to perfectly reachable Mail Server

ACTUAL RESULT:

Android MUA doesn’t try to connect to perfectly reachable mail server.

ADDITIONAL INFORMATION:

Sailfish seems to do similar internet connection testings like MS ncsi… It uses ipv4.jolla.com e.g.
My strong guess is, that the connection as marked ‘no-internet’ if the test fails.
This ‘no-internet’ flag seems to get passed over to Android.
Wich leads to non-working Apps although everything is as intended.
Of course, easy to fix on the LAN side, but wrong way.
Sailfish doesn’t have to judge about internet connectivity. At least, this classification test, which is proven to give wrong results, must be user-switchable. Internet routing mustn’t affect networking in general.

2 Likes

It happens as well if you connect to the access point of your (Nokia) camera to remote control the camera or download pictures.
As the camera doesn’t provide Internet access phone and camera only have a (operational) local network. However AlienDalvik claims it’s not connected to the internet. In the pure sense it’s correct, however due to that the camera app doesn’t connect to the camera.

I would consider it a bug in the application if

  1. application does need a network
  2. application may use but does not need internet access
  3. application relies on “do we have internet” function of OS which only verifies 2.

like you describe.

Does the MUA actually work differently on “real” Android, in the situation there’s access to a network (with mail server), but not the internet?

Yes, k9 on Huawei Android (google-free) works flawlessly on the same LAN.
@Jolla, please not that this also affects internal destinations:
Bromite does not contact internal web-servers if SailfishX-Verla (4.2) doesn’t have NATed internet access. This is a severe bug for android compat apps. The Sailfish browser isn’t affected, it connects to internal servers regardless if “internet was detected” sucessfully (NATed and not blocked to ipv4.jolla.com).

Could this be the cause of the issue raised on other threads about WLAN connectivity for Android apps?

Is there an option to check the Android connection state via the terminal? I’d love to find out, if my connection issues within the Adnroid apps result from this.

Still an issue with Suomenlinna (4.3 release).

The real issue is the evaluation rule for ipv4.jolla.com.
I cannot create an IMAP account (on 4.3) if I;m connected to a WiFi LAN, which doesn’t grant public internet access, but can perfectly reach our mail servers.
This is ridiculous, I had to fake the HEAD /return_204 response in order to create my IMAP account.
Jolla, please stop trying to restrict your users decisions abot network conectivity with such useless and wrong implemented checks.
It’s perfectly valid to use the ipv4.jolla.com check in order to determine if a captiv portal signin might be requierd, but it’s not correct to justify if user is allowed to create an IMAP account based on the result of this check.
And it’s completely wrog to tell the android subsystem that WiFi is switched off if the check didn’t succeed.
I can imagine that lots of the reported Android-WiFi-regressions have a similar context - the connectivity check failing due to filtering/routing/private DNS erc.

I have a similar issue with skype using two different ISPs. Sometimes Skype works, but mostly it cannot connect to skype network. I tried to ping

ipv4.jolla.com

I have to replace it with [DEAD_SRV] due to forum restriction on the number of links in a mail. It prohibits posting traceroute logs.

while skype could not connect and got this:

$ ping [DEAD_SRV]
PING [DEAD_SRV] (63.32.167.217) 56(84) bytes of data.
^C
— [DEAD_SRV] ping statistics —
18 packets transmitted, 0 received, 100% packet loss, time 17450ms

And here is traceroute, which ends somewhere inside amazon…

$ traceroute [DEAD_SRV]
traceroute to [DEAD_SRV] (63.32.167.217), 30 hops max, 60 byte packets
1 gate.homenet ([MY_LAN_IP]) 0.498 ms 0.644 ms 0.817 ms
2 [MY_WAN_IP] ([MY_WAN_IP]) 3.418 ms 3.409 ms 3.477 ms
3 [MY_ISP_GATE1] ([MY_ISP_GATE1]) 3.468 ms 3.568 ms 3.559 ms
4 [MY_ISP_GATE2] (79.98.8.253) 3.639 ms 3.816 ms 3.808 ms
5 decix2.amazon.com (80.81.195.152) 59.299 ms 57.038 ms 59.689 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 *^C

I and my devices can acces all Internet except [DEAD_SRV]?