Fix ICE/UPnP handshake on some common German ISP routers

[Elv13]

Apparently Deutsche Telekom, T-Mobile and FRITZ!Box devices are affected by less or more (hopefully), the same issue.

Relevant protocol documentation:

https://tools.ietf.org/html/rfc6886 https://tools.ietf.org/html/rfc6970 https://tools.ietf.org/html/rfc5245

Mitigation:

• Disable UPnP in the advanced settings

Long term solution:

• Have a troubleshooting module / wizard to auto-detect and auto-setup some network settings using a DTMF echo test.

[star-buck]

So if ring was working fine with any of the non-appimaged versions previously between the same participants this seems irrelevant. I also tried gnome ring and it was working fine as well, never changed the router between then and now. Will simply try and call myself on the phone from 1. the appimage and 2. ring gnome today to see what happens in case anything has changed on my friends side, though he reports not changing anything as well.

[Elv13]

So if ring was working fine with any of the non-appimaged versions

Does it for you? It turned out my issue was a time calculation bug in the security validation code and not related to the network stuff. Once I got that fixed (its probably not your issue) it started working again with the appimage.

So your issue is neither the one described above nor the one I originally had. I will need more information to figure out your problem.

• The exact daemon version and where it comes from
• The Gnome client version and where it comes from
• Does it work if you disable UPnP as described above (it could be a recent daemon regression, the appimage use the Git master branch)
• The appimage logs (terminal output), please remove any 40 char hexadecimal id to preserve the privacy of your peer identity (unless you don't care and its a throwaway account)

But that's overall good news. It proves it's not a problem with the single application packaging and/or the static toolchain.

[star-buck]

Yeah, I can confirm the ring-kde appimage works with the latest ring android client! 👍 Now I also installed ring-kde and ring-daemon manually on netrunner rolling, so im not sure this is what made it work. Will uninstall everything now to see if it still works with android <-> ring-kde.appimage.

[star-buck]

sidenote: for testing this appimage method seems awesome, i just wonder what happens when closing the appimage since the daemon then stops being active to monitor incoming calls?

[star-buck]

happy to confirm: appimage version still runs fine without anything else installed, completely removed ring-kde and ring-daemon previously installed and ended process "dring" manually. Still able to make a video call to the android client and viceversa. Great!

[Elv13]

Will uninstall everything now to see if it still works with android <-> ring-kde.appimage.

Ok, good. A distributed media handshake is always a rather complex process. It's good to know there isn't a systemic problem I couldn't reproduce. Those are always a terrible pain to debug.

i just wonder what happens when closing the appimage since the daemon then stops being active to monitor incoming calls?

The appimage has no deamon at all. I could not use a daemon since the Gnome and KDE client could not have worked on the same system (as they may use different/imcompatible daemon version and it would cause dataloss and crashes, including losing accounts due to the lack of backward compatibility between the major account versions). So when ring-kde quit, everything stops. In the static/appimage mode, Ring-KDE handle the calls itself instead of talking to the daemon.

appimage version still runs fine without anything else installed

Perfect, that's what took me 1 week to ensure, glad to know the work paid off.

ring-daemon previously installed and ended process "dring" manually.

Ah, I think that explains it. When you first tested, you probably had both the daemon and the appimage running at once. So in fact you had 2 listener on the same network interface. Chat randomly worked because it supports multiple end points, but SIP locked important ports to itself. So the "wrong" Ring "daemon" tried to pickup the call, but had no clients to actually send the command.

I can add a script to auto-detect this corner case when the appimage starts and open a popup.

[star-buck]

i think its fine for testing until we enter beta or RC phase. lets continue with making alphaX appimages and perfecting these.

[Elv13]

Ok, should I get back on the "older" systems support and the theme now? An user also reported a crash, I will fix it too. I will work a bit today because I lost some time 2 days ago due to the storm.

I finally got a semi affordable bus ticket (they currently cost their weigh in gold until the central railways re-open...), so I should arrive in Berlin late today.

[Elv13]

Bugs created for the port locking race condition/collision

https://bugs.kde.org/show_bug.cgi?id=385461