Open nightvisi0n opened 4 years ago
Hi, thank you very much for your feedback. I'm sorry for my late reply, being very busy over the last months so I didn't visit my account for some time. Thank you for your detailed problem report, I'll see what I can do as soon as possible. Have a wonderful day. Best regards, Roland
Hi, did you have time to have a closer look at it? I just tried it on my Pi Zero W with the latest Raspberry Pi OS as well and incoming calls aren't working for me either. Outgoing calls ring at least, I have not tried to see if I am heard. And I had to disable ufw during the test, because I have no idea how to add a correct rule for it to get it to work. Do you need additional logs? (How can I create the tcpdumps?)
Thank you for your great tool, I hope you can get it working again sometime :-)
Just my workaround for this problem. I use Tasker to disable wireguard in my home network and restart the fritzfon app and connect wureguard when leaving my home network.
Hi, I am sorry but I cannot reproduce what you describe. Here are at least 7 sites where fapfon-proxy is used all the time, exactly working as described. My personal settings are FRITZ!Box 7490 (FRITZ!OS 07.21) and FRITZ!APP FON 4.1.8 on iOS14.3, OpenVPN server and fapfon-proxy running on a Raspberry Pi 3 Mod. B+ in my home network. Please note that the iptables configuration is essential so that the SIP packets are really going through fapfon-proxy. If you don't have an appropriate iptables configuration, SIP packets go to the FRITZ!Box directly and fapfon-proxy has no effect. You might use the fapfom-proxy --dump option to check what happens exactly. Hope this helps. Best regards, Roland
Hi Roland, sorry for my late response. I just tried it again and it's still not working. Maybe something else is wrong in my setup. May you have a look at the logs I attached? (They look ok to me, as far as I understand your technical details in the readme.)
IPv4 | Host |
---|---|
192.168.2.99 | Pi-hole and PiVPN (with WireGuard) |
192.168.2.1 | FRITZ!Box |
10.6.0.2 | Fritz!App Fon VPN address |
I'm using a FRITZ!Box 7590 (also FRITZ!OS 07.21) with FRITZ!App Fon 4.1.8 also on iOS 14.3
Ah and regarding ufw, I just had to execute sudo ufw allow 5060 so no big issue here, I think I was confused about the random ports on the client side.
I created two dump logfiles with an outgoing call via an active VPN connection. The prerouting looks fine to me and if I'm starting the service the fapfon-proxy.log content also looks fine to me. Without VPN the FRITZ!App Fon is working quite fine, and with VPN it makes no difference if ufw is on or off.
dump_BOX.txt dump_FON.txt fapfon-proxy.log PREROUTING.txt
@charliesz I'm using iOS so Tasker isn't an option for me, but I tried it manually and it makes no difference in my setup. Wireguard automatically connects if I'm not connected to my home Wifi anymore and automatically disconnects if I'm connected again. I tried it with an opened FRITZ!App Fon while connected to Wifi and then I disconnected my Wifi.
Best regards Markus
Same issue here. With wireguard and fapfon on a rpi, you can establish an outgoing call, but no voice is heard on either side. I can provide logs if necessary.
Here we are experiencing the incoming call issue as well. Everything else is fine.
When trying to call the Fritz!App Fon, the call doesn't get through. In the log we find: 211013 171710 V3 Box address 192.168.11.1:5060 211013 171710 V3 TCP: Server SIP port 5060 211013 171710 V3 UDP: Server SIP port 5060 211013 171710 V1 Start fapfon-proxy version 0.3.1221 211013 172630 V3 [1] Connect 100.64.0.101:40124/udp, contact 'SHIFT6m-qCJc7NtE' 211013 172645 V3 Failed to process packet: No Via header 211013 172645 V3 Failed to process packet: No From header 211013 172645 V3 Failed to process packet: No To header 211013 172645 V3 Failed to process packet: No Content-Length header 211013 172645 V3 [1] Packet from 100.64.0.101:40124/udp not recognized - disconnecting 211013 172645 V2 [1] Disconnect 211013 172700 V3 Failed to process packet: No Via header 211013 172700 V3 Failed to process packet: No From header 211013 172700 V3 Failed to process packet: No To header 211013 172700 V3 Failed to process packet: No Content-Length header 211013 172700 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172715 V3 Failed to process packet: No Via header 211013 172715 V3 Failed to process packet: No From header 211013 172715 V3 Failed to process packet: No To header 211013 172715 V3 Failed to process packet: No Content-Length header 211013 172715 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172731 V3 Failed to process packet: No Via header 211013 172731 V3 Failed to process packet: No From header 211013 172731 V3 Failed to process packet: No To header 211013 172731 V3 Failed to process packet: No Content-Length header 211013 172731 V3 Packet from 100.64.0.101:40124/udp not recognized 211013 172731 V3 [2] Connect 100.64.0.101:40124/udp, contact 'SHIFT6m-qCJc7NtE'
...where 100.64.0.101 is the address of the phone connected via WireGuard.
I am also attaching two dumps (FON / BOX) of failed calls to the Fritz!App Fon. There are Via/From/To - headers present in the dumps.
Hello tboerner,
This is very helpful, thank you. However, at the moment I don't see how the failure messages are related to the dumped packets, so I would like to ask you to create a combined dump/log file using a command line like below:
This will create a "log/dump all" file named fp.log in your current directory. The --dump output goes to stdout, the -l- switch causes the log messages to be output to stdout as well, the 2>&1 is there in case anything is output to stderr.
Best regards Roland Genske
Hey Roland,
Of course - I was just wondering how to do it.
What I did:
Best, Thomas fp.log
Hello Thomas,
I just pushed a new version with additional hexdump diagnostics in case a packet cannot be processed. If possible, please repeat the test invocation using this new version, I hope that this will indicate the cause of the problem.
Best regards Roland Genske
Hello Roland,
here you are. I'm under the impression the unrecognized packets are just empty: 0d 0a
Cheers, Thomas fp.log
Thank you Thomas, these appear to be SIP keep-alive packets, as I just learned. Just preparing a new release.
New release just pushed, hoping that this solves the problem. Could not test it because those empty packets don't appear in my environment (iOS, OpenVPN).
Thanks for your quick reaction, Roland! Unfortunately the Fritz Fon App still doesn't ring. fapfon-proxy now complains incomplete packets.
Sorry, overlooked that the next_packet() caller did not accept incomplete UDP packets. Just pushed new release.
Sorry, no success yet. No complaints about incomplete packets any more, but no ring either. Double-check w/o VPN and fapfon-proxy works.
Thomas,
Thank you very much for your great help. It seems that there are significant differences in how the FRITZ!App Fon works on iOS vs. Android. The proxy assumes that the contact contains the private mobile phone provider address, which appears to be different on Android. As a consequence, the address is not rewritten so that the Box does not connect to the proxy on incoming calls. I need to check this in detail. You could help me by creating another log, this time about an outgoing call (completely with pickup and hangup), if possible. Please check whether or not you hear audio (on both sides) during that call. You can, of course, obscure the phone number in your log if you want. This would be very helpful, thank you very much.
Best regards Roland Genske
Roland, Well, take it as my way to thank you for your work and your effort to make it available to a greater public :-)
fp-out.log contains a complete outgoing call from the Fritz App Fon to an external number. Audio was ok in both directions. fp-in.log shows an attempt to call the Fon App from the same external number. The App did not ring, as expected. I am adding this because before I always tried to call the Fon App from another DECT phone connected to the same Fritzbox (internal call). Perhaps you can see a difference.
Thanks again, and best regards Thomas
Hello,
at first: thanks for this great project. Wondering why it hasn't got more attention yet. I've setup it in order to use Fritz!App Fon over a Wireguard VPN. Outgoing calls now work fine, but I'm struggling with incoming calls. They don't reach the Fritz!App Fon. According to the tcpdump logs below, it seems like the
NOTIFY
andINVITE
SIP-messages have the wrong destination IP-Address.Addresses
10.5.1.51
10.5.1.11
10.5.10.10
192.168.1.101
Logs
fapfon-proxy
``` Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 Box address 10.5.1.11:5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 TCP: Server SIP port 5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V3 UDP: Server SIP port 5060 Apr 01 16:47:01 wireguard fapfon-proxy[7822]: 200401 164701 V1 Start fapfon-proxy version 0.3.1221 Apr 01 16:47:31 wireguard fapfon-proxy[7822]: 200401 164731 V3 [1] Connect 10.5.10.10:59484/udp, contact 'JulnsiPhone_WIGI45ak' ```REGISTER, SUBSCRIBE, NOTIFY tcpdump
``` IP 10.5.1.51.59741 > 10.5.1.11.5060: UDP, length 563 E..O.V@.@.j. ..3 ....]...;..REGISTER sip:fritz.box SIP/2.0 Via: SIP/2.0/UDP 192.168.1.101:63346;rport;branch=z9hG4bKPjUh8D15qIqUsW7IFIVwvOCClSqsT.5jsU Max-Forwards: 70 From:INVITE tcpdump
``` IP 10.5.1.11.5060 > 192.168.1.101.64053: UDP, length 1191 E.......@..S ......e...5....INVITE sip:JulnsiPhone_WIGI45ak@192.168.1.101:64053;ob SIP/2.0 Via: SIP/2.0/UDP 10.5.1.11:5060;branch=z9hG4bK44DCAD7B042159A1 From: "Julian Neureuther"