asked 2018-04-26 19:30:26 +0200
So it happens pretty often that on my XPeria X, Whatsapp (even tho open and functional) does not deliver messages; nor receive them for longer periods of time; even with device in data / wifi range (for instance browsing works fine).
What is this? Service stuck?
answered 2018-04-29 15:32:36 +0200
I found at least something significant: NAT timeouts.
I've been now running tcpdump -n -i wlan0 -s 256 port not 22 for over an hour, and netstat -natp, both in root shells
Currently relevant part of netstat -natup output is:
tcp 0 363 myipv6:55876 2a03:2880:f20a:c6:face::443 ESTABLISHED 5097/com.whatsapp
tcp 1 0 myipv6:52013 2a00:1450:400f:806::200:443 CLOSE_WAIT 5097/com.whatsapp
tcp 38 0 myipv6:58590 2001:14b8:1800:401:face:443 CLOSE_WAIT 5097/com.whatsapp
WhatsAPP thinks the first, ESTABLISHED is live. It is not -- wlan NAT has forgotten it already. in tcpdump output
I saw dozen packets with Flags [P.] attempted to be sent to that remote address (with increasing delay between attempts). And no ACKs to those!
Probably, as whatsapp tries to save network bandwidth it has first been silent too long and it's tcp6 connection has been reaped from NAT. When it then tries to send packets it just doesn't recognize that it cannot get those through.
(I'd be interested how WhatsAPP on android devices work -- does the android layer there work better or ...?)
The other 2, CLOSE_WAIT lines are interesting. The one with source port 52013 has been there over an hour.
From https://stackoverflow.com/questions/15912370/how-do-i-remove-a-close-wait-socket-connection
I.e. WhatsAPP has, for some reason, not closed the tcp6 socket fo these connections. It probably just leaked the fd's (as there is no heavy read(2)/poll(2) activity -- well top(1) doesn't show anything going on there).
ls /proc/5097/fd shows com.whatsapp has currently 141 file descriptors open. most probably for IPC between other local processes (or itself!), but probably also at least those 2 garbage fd's)
Wow cool find! Seems more like whatsapp is leaking connections to me. Some connection reaper is not invoked properly on the whatsapp side?
About the NAT timeouts; could be that Whatsapp is not sending keepalive messages to keep the connection open.
tortoisedoc ( 2018-04-29 20:17:55 +0200 )edithttps://www.onsip.com/blog/what-is-nat-keepalive -> sounds close to what we are experiencing (as behavior); but is VoIP.
here's a keep-alive protocol relevant for SIP (video & audio calls).
tortoisedoc ( 2018-04-29 20:24:46 +0200 )editId absolutely love to check this out, but it seems https://releases.jolla.com/releases/2.1.4.14/jolla/armv7hl/ does not have tcp dump..
tortoisedoc ( 2018-04-29 21:20:08 +0200 )editGot the package from OBS. It seems there's no STUN / CRLF activity on the tcp; so I wonder if it's udp keep-alives Now If I could only get wireshark to work on jolla..
EDIT : ha! https://openrepos.net/content/nieldk/wireshark
EDIT2 : would have been nice, but doesnt work.
tortoisedoc ( 2018-04-29 21:37:13 +0200 )editanswered 2019-09-17 11:23:26 +0200
It seems like there is still no solution to this. I recently tried sending a ping every five mins but this, strangely, only helps when I'm connected via Wifi and not via changing mobile networks. It happens that the ping sees "network down" or even "100% packet loss". In that case, no connection at all is possible until "something" happens and it works again. Then there is a situation where a normal ping is successful but Android still has no connection. Usually switching mobile data off and on helps here but I have no means to detect such a scenario and have to do it manually. There must be some kind of fix for it and if nothing else helps I'm going to reset mobile data every five minutes via script. Really unsatisfactory though.
answered 2018-05-02 17:41:47 +0200
Whatsapp does not seem to set SO_KEEPALIVE (netstat -natoup); hence its a mystery how the keepalive can affect it in the first place, given apps have to request it explicitly (here) . This is starting to sound like a connman issue; is that plausible?
https://stackoverflow.com/questions/6565667/how-to-set-the-keepalive-timeout-in-android
this is how androide sees linux keepalives;
..and this is the netd client side of things (done via unix domain sockets).
tortoisedoc ( 2018-05-04 07:30:31 +0200 )editHow can I emulate a half-closed connection due to wifi signal range falloff?
tortoisedoc ( 2018-05-04 23:42:54 +0200 )editOn the android side; ConnectivityManager provides network status to apps (I assume whatsapp as well); ConnectivityManager in turn is a facade of ConnectivityService. And in ConnectivityService.java, we have keep alive timeouts definitions:
these seem to be stored in some global database, however. It remains to be seen how /proc definitions come into play.
From here, there is a picture (perhaps outdated) of the wifi stack:
https://elinux.org/images/9/98/Dive_Into_Android_Networking-_Adding_Ethernet_Connectivity.pdf
and to tackle the issue from the eastern front (i.e. kernel / iptables):
https://bugzilla.redhat.com/show_bug.cgi?id=1215927
tortoisedoc ( 2018-05-05 01:55:52 +0200 )editAsked: 2018-04-26 19:30:26 +0200
Seen: 1,209 times
Last updated: Sep 17 '19
look my question for the same yesterday. we'll have to dig deeper. i used whatsapp web to help. for me whatsapp work better when on mobile network...
too ( 2018-04-26 20:23:13 +0200 )editIs "browsing" with an Android app (e.g. Firefox)?
Background:
On my Jolla 1 all Android apps almost always lose network access, when SFOS automatically switches from mobile network (3G in my case) to a known WLAN. Some apps show this (e.g. Firefox), some don't (e.g. Conversations).
"Restarting network" per Sailfish-utilities usually makes no difference then, but restarting AlienDalvik always does. And sometimes (rather rarely) network access for Android apps over WLAN starts working automatically a while (many minutes) after such a network switch.
I found a couple of reports here on TJC, which may be related to this, but none of them was detailed enough to check if this is the same issue (or to narrow it down even further).
olf ( 2018-04-26 20:28:49 +0200 )editThus, can you please check that you are seeing the same behaviour.
@olf : nope, browsing occours with native browser. EDIT : unless you mean "browsing with an android browser"; in my case this was opera, and i Happened to use it some time before this happened (few days). Note that I cant recall if I rebooted the phone in between. It is also true that I switch daily between office & home. Also restarting network did not seem to help; I had to reboot the phone.
tortoisedoc ( 2018-04-26 20:34:26 +0200 )edit@tortoisedoc, well then please test other Android apps, when (i.e. right after) Whatsapp fails for you, so you know, if you are hunting down an issue with Whatsapp under SFOS / AlienDalvik or one WRT the AlienDalvik integration into SFOS.
Well, this seems to be at least similar to what I described above.
And that you don't need to reboot (see there).
Please do test.
olf ( 2018-04-26 20:39:14 +0200 )editI tested using WhatsAPP Web -- using that for all activities and leaving Xperia X on the table. After a while I get message 'Phone not connected' on web browser window. Now when I tried to ping 9.9.9.9 it did not make any difference, but when starting Chrome Android browser and surfing a bit WhatsAPP Web became alive again. This was just a brief experiment, have to try more.
More details of my case in https://together.jolla.com/question/183306/whatsapp-delays-on-certain-wifis-works-fine-on-mobile-network/
too ( 2018-04-27 00:53:18 +0200 )edit