Open takiainen opened 1 month ago
hi @takiainen, what version of Meshenger are you using? It would be also helpful if you could try with these version and let me know if they work for you:
That would help a lot. We are trying to fix this problem, but have to identify the fix yet.
Also make sure that the contacts IP address is correct (see contact details).
I had v4.3.0 from F-Droid.
Now I tried v4.3.2 as well, but it doesn't work either.
IP addresses are correct.
hm, that is weird. Meshenger connects to IP addresses. Maybe your tunnel does not forward TCP/IP connections or there is even some firewall involved.
I am far from being an expert regarding wireguard or firewalls, but at least I can access my surveillance camera feeds and Nextcloud instance through it without any issues.
I used this guide to set up Wireguard instance on my home router: https://blog.usman.network/posts/wireguard-vpn-on-a-ubiquiti-edgerouter/
There's one section regarding the firewall too.
But maybe wireguard VPN isn't optimal for this kind of messaging app?
I do not see why wireguard should not work. What App do you use to connect your phone via wireguard?
I use this: https://www.wireguard.com/install/ (Android version)
Are the IP addresses of both phones in the same network? have you tried to connect both phones directly via VPN tunnel?
Both are in the same network and both use the same wireguard VPN (same app also).
Other phone's IP is 10.10.69.2 and the other 10.10.69.7.
On each phone Meshenger shows other phone as "online" (green dot).
I can confirm the problem. The contact is green, the other phone rings and after accepting the call even some sounds can be heard. But then the connection breaks down. I need to analyse the traffic to figure out what is happening.
I have a simple Wireguard setup now that works (wireguard from to phone to a server on the Internet, one via mobil data only, the other some Internet AP). I suspect the problem is that webrtc tries to do be smart and uses other routes and fails.
For testing please make sure that all traffic goes via VPN and there is no way WebRTC can send the packets via some other interface.
Hello, I'm also have having trouble connecting over a VPN tunnel. I can make a brief call, it answers and immediately hangs up, but you can hear a few sounds. The green/orange status circles are sporatic. Calls work fine over a LAN IP.
I'm running an OpenVPN server, with the Android clients running OpenVPN for Android. --client-to-client is enabled on server with UFW rules, etc configured for peer communication. I have web servers connected to the VPN and their tun IP is accessible from both Androids. I verified Android-to-Android tun connectivity works in both directions by using the wifi transfer plugin for Total Commander (it basically runs a small web server to share files). Currently only using IPv4.
How do I ensure "there is no way WebRTC can send the packets via some other interface"? Aren't you using a bundled WebRTC library in the APK, so where are the settings?
Originally started with the 4.3.3 F-Droid version but appear to have same results on 4.3.2 and 4.3.4.
I haven't tried yet but do exceptions write to the ADB logs?
Both phones have root access so I can test further if you have any ideas. netstat output is the same regardless of IP's chosen in the settings:
tcp6 0 0 [::]:10001 [::]:* LISTEN 20339/d.d.meshenger
hi @bob04619 , any help is apprechiated.
Best would be to capture the packets on the caller and callee system (e.g. use PCAPdroid) and see if Meshenger (WebRTC) tries to send packets to other addresses then the destined target address. Also try to make sure that all traffic (even for the Internet) is forced through the VPN tunnel.
Also you could try Meshenger 4.3.1 (https://github.com/meshenger-app/meshenger-android/releases/tag/v4.3.1). It has a patched WebRTC (contains https://groups.google.com/g/discuss-webrtc/c/pTWe0QLKNC4/m/_ulh_2NJBwAJ). It that works, then that would give us a big clue.
Also userful would be to compile meshenger yourself. By default it will print all the debug out (viewable via Logcat) . there you can see what IP addresses will be in the WebRTC offer (https://github.com/meshenger-app/meshenger-android/commit/ff15c28bbec995300ef2d65003a4ba037559843f). You can then check if these are only the intended target IP address or localhost address and not any other address.
btw.: my test setup correctly does not show any problems. so that is hard to debug :/
@mwarning Testing tcpdump on VPN server with both clients' OpenVPN for Android forcing everything through the tunnel including local traffic.
Phone 1 on cellular, 10.7.0.2 tun0 / 192.168.72.251 wlan0 Phone 2 on WIFI, 10.7.0.6 / 192.168.43.5
In one test of a disconnected call from Phone 1 in the pcap I'm seeing 10.7.0.2 streams trying to reach 192.168.43.5 (STUN Binding Request user...). I don't see a 10.7.0.2 to 10.7.0.6 stream so not sure what made the phone ring.
When I shared/added contacts I only used the tun0 IP.
I will see if I can add the server certificate to wireshark or disable VPN encryption. Or will all of the WebRTC chatter be encrypted?
@bob04619 WebRTC traffic is encrypted by default. We very likely cannot disable that. But I do not think WebRTC traffic is important except for the source/target IP address/port.
@bob04619 the way WebRTC works is that you generate an offer that contains the (own) hosts IP address and audio/video capabilities. That offer needs to be transferred outside of the WebRTC library. Meshenger establishes TCP/IP connection to the destination and send this offer. The called phone then feeds that offer to WebRTC. This is where then WebRTC establishes the connection.
In one test of a disconnected call from Phone 1 in the pcap I'm seeing 10.7.0.2 streams trying to reach 192.168.43.5 (STUN Binding Request user...). I don't see a 10.7.0.2 to 10.7.0.6 stream so not sure what made the phone ring.
Maybe Meshenger fails to disable STUN...
@bob04619 the phone rings if the initial exchange of the WebRTC offer (just a string blob via TCP/IP) was successful. Then WebRTC takes over and needs to create the actual audio/video connection (UDP).
The problem is likely that the WebRTC offer contains a different IP address compared to what the initial (TCP/IP) connection uses to exchange that offer (and then triggers the ringing).
I will ask on the discuss-webrtc mailing list on how this can be fixed.
I tried to fix the VPN issue. But I am not sure if it is fixed. I have create a pre-release apk for testing. Please update the caller and callee:
https://github.com/meshenger-app/meshenger-android/releases/download/v4.3.5/meshenger-4.3.6-pre.apk
Please try it out and let us know! Thank you.
@mwarning I just tried, it may work slightly different, but it still hangs up after a second or two, it goes from Waiting -> Connecting -> Error. The contact status circles seem to stay green longer, and sometimes the caller phone says Connected a while even though the callee's phone hungup.
I tried with VPN connected ignoring pushed routes, as well as tunneling all routes.
Also, not sure if related but another issue if we can fix the first problem - when I have my tether wifi hotspot turned on on one phone, most times I can't make or receive calls, and the status goes red. It's a little inconsistent though. I'm using this Magisk module to get around AT&T's tether check, I think they use some IP Tables rules, I think for TTL:
https://github.com/evdenis/tether_unblock
To make sure there's no suspect IP Tables rules left behind, I rebooted this phone and tested before using the hotspot, but it behaved the same as I described at first. (with 2nd phone connected to a different hotspot)
@mwarning I also tried disabling the Tether module and rebooting, but same hang-up error. The only other module I use is the built-in Systemless Hosts. On the second phone I'm using some modules for Play Integrity fix. I doubt this stuff would cause a problem with connections but I can test later with a friend's non-rooted stock phone.
Also, in case my non-stock phone is causing problems - the first phone has no Google Play stuff whatsoever, the second phone runs MindTheGapps. Both phones are running this GSI ROM:
@bob04619 thank you very much for testing. Sad to hear that it does not work for you. But does 4.3.6-pre work when previous versions also work? Then at least I (probably) won't break anything.
@mwarning Do you mean does it still work with LAN based calls? Yes that appears to still work fine, as well as if one phone is connected via WIFI to the other phone's hotspot. However I've never tested any of the versions more than a minute or two.
@mwarning Do you mean does it still work with LAN based calls? Yes that appears to still work fine, as well as if one phone is connected via WIFI to the other phone's hotspot. However I've never tested any of the versions more than a minute or two.
Yes. Thank you for letting me know. It is important not to break anything.
Two mobile phones are connected to the same home network via wireguard VPN. They see each other (ping works). Phone call using meshenger gets through (other phone shows incoming call), but when you try to answer, "error" is displayed.
Both are using the latest version from F-Droid.
What might be the problem?