Jitsi-meet Android app disconnected

Hi,

I installed jitsi-meet on Debian (stable), and it works fine from any Google Chrome client on desktop PCs. However, I’m having issues with the Android app on Play Store.
I go to settings and specify my server’s base URL (just like I would in Chrome on a desktop but without the room name). Then I enter the room name in the text input box. The app immediately shows the message: “You have been disconnected.”.

On the Debian server my Apache access log usually shows connections like these:

meet.mydomain.org:443 10.1.2.12 - - [27/Mar/2020:08:33:56 +0100] “POST /http-bind?room=test HTTP/1.1” 200 2864 “https://meet.mydomain.org/test” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0”

However, when using the Android app with my custom https://meet.mydomain.org/ server URL set in Settings, my Apache access log does not record anything.

Any ideas?

I’ve made some changes.
A tcpdump on the firewall in front of the Jitsi-Meet server actually does record traffic now:

# tcpdump -i ppp1 -n host Android_client_IP
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp1, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
08:55:15.430010 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [S], seq 2198840817, win 65535, options [mss 1390,sackOK,TS val 98502938 ecr 0,nop,wscale 8], length 0
08:55:15.430229 IP Jitsi-Meet_Server_IP.443 > Android_client_IP.19968: Flags [S.], seq 1615883892, ack 2198840818, win 64800, options [mss 1452,sackOK,TS val 511062481 ecr 98502938,nop,wscale 7], length 0
08:55:15.501135 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [.], ack 1, win 326, options [nop,nop,TS val 98502965 ecr 511062481], length 0
08:55:15.513524 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [P.], seq 1:190, ack 1, win 326, options [nop,nop,TS val 98502966 ecr 511062481], length 189
08:55:15.514886 IP Jitsi-Meet_Server_IP.443 > Android_client_IP.19968: Flags [.], ack 190, win 505, options [nop,nop,TS val 511062565 ecr 98502966], length 0
08:55:15.530613 IP Jitsi-Meet_Server_IP.443 > Android_client_IP.19968: Flags [.], seq 1:1379, ack 190, win 505, options [nop,nop,TS val 511062581 ecr 98502966], length 1378
08:55:15.531547 IP Jitsi-Meet_Server_IP.443 > Android_client_IP.19968: Flags [P.], seq 1379:2656, ack 190, win 505, options [nop,nop,TS val 511062581 ecr 98502966], length 1277
08:55:15.606508 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [.], ack 1379, win 337, options [nop,nop,TS val 98502991 ecr 511062581], length 0
08:55:15.609636 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [.], ack 2656, win 348, options [nop,nop,TS val 98502991 ecr 511062581], length 0
08:55:15.609638 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [P.], seq 190:197, ack 2656, win 348, options [nop,nop,TS val 98502991 ecr 511062581], length 7
08:55:15.610895 IP Jitsi-Meet_Server_IP.443 > Android_client_IP.19968: Flags [F.], seq 2656, ack 197, win 505, options [nop,nop,TS val 511062661 ecr 98502991], length 0
08:55:15.616426 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [R.], seq 197, ack 2656, win 348, options [nop,nop,TS val 98502992 ecr 511062581], length 0
08:55:15.691948 IP Android_client_IP.19968 > Jitsi-Meet_Server_IP.443: Flags [R], seq 2198841014, win 0, length 0
^C

And a dump on the Jitsi server’s NIC shows this (never mind the timestamp):

#  tcpdump -i enp5s3 -n host Android_client_IP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s3, link-type EN10MB (Ethernet), capture size 262144 bytes
09:48:19.869528 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [S], seq 4030795067, win 14600, options [mss 1460,sackOK,TS val 196437843 ecr 0,nop,wscale 2], length 0
09:48:19.869583 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [S.], seq 1114598512, ack 4030795068, win 28960, options [mss 1460,sackOK,TS val 1319742 ecr 196437843,nop,wscale 8], length 0
09:48:19.869724 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [.], ack 1, win 3650, options [nop,nop,TS val 196437843 ecr 1319742], length 0
09:48:19.873968 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [P.], seq 1:190, ack 1, win 3650, options [nop,nop,TS val 196437843 ecr 1319742], length 189
09:48:19.874016 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [.], ack 190, win 118, options [nop,nop,TS val 1319743 ecr 196437843], length 0
09:48:19.991244 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [P.], seq 1:1992, ack 190, win 118, options [nop,nop,TS val 1319772 ecr 196437843], length 1991
09:48:19.991533 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [.], ack 1449, win 4374, options [nop,nop,TS val 196437855 ecr 1319772], length 0
09:48:19.991568 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [.], ack 1992, win 5098, options [nop,nop,TS val 196437855 ecr 1319772], length 0
09:48:20.027992 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [P.], seq 190:197, ack 1992, win 5098, options [nop,nop,TS val 196437858 ecr 1319772], length 7
09:48:20.028054 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [.], ack 197, win 118, options [nop,nop,TS val 1319782 ecr 196437858], length 0
09:48:20.029417 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [F.], seq 1992, ack 197, win 118, options [nop,nop,TS val 1319782 ecr 196437858], length 0
09:48:20.029634 IP Android_client_IP.34748 > Jitsi-Meet_Private_IP.443: Flags [F.], seq 197, ack 1993, win 5098, options [nop,nop,TS val 196437859 ecr 1319782], length 0
09:48:20.029689 IP Jitsi-Meet_Private_IP.443 > Android_client_IP.34748: Flags [.], ack 198, win 118, options [nop,nop,TS val 1319782 ecr 196437859], length 0
^C

However, I am NOT seeing anything in my Apache access log for this particular Android_client_IP. I am seeing other clients connecting but not this one.

The jicofo log file doesn’t show me anything regarding this Android client either.

What can I try?
Would a pcap be of any use here?

What about certificates, do you have a valid fullchain of certs? This is a mobile requirement.

Hi,
I had the same issue on iPhone and here is what I had to do to get rid of it :

  • remove the « auth_basic » setting I had in my nginx conf
  • remove my name / email in the settings of the app
  • put both « advanced options » in the app on « on » (Green button)

And then it worked !

Good luck

As reported in another forum post, the Let’s Encrypt script is apparently buggy so I can’t create a valid fullchain of certs. I am using a self-signed certificate, but I’ve read in another forum post that it is not valid for the mobile app.

Thanks, but your hack does not work for me. I tried your settings on the app, and my installation uses Apache, not nginx. However, my Apache config does not use “basic auth”.

I have the same problem but couldn’t find any solution.
I am waiting for someone give the correct answer.

In my particular case I had firewall issues that blocked the let’s encrypt servers’ access to my HTTP server (via ACME). Also, after figuring that out and successfully running /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh, I also had to run certbot install in order to actually include the newly-generated certs into the virtualhost configuration.

Now I can access my server with the Jitsi-Meet Android app.

1 Like

experienced similar issue with apache. Lets encrypt Error log shows nginx …
sudo rm -f /var/log/nginx/*

ran letsencypt script again…resolved issue