After Core 153, Discord Cam no longer working

Can no longer upload to my Nextcloud server. Seems this update has hit many of my services now. I cannot access it from my phone or computer. Which means my firewall rule to allow pass through is no longer honored by the firewall rules.

After doing a fresh install 153, these issues persist except for the NextCloud Server issue.

However, I am just going to move to a different OS. Thanks for your time!

I can confirm that I was having the same problem, and that it only resolved after rolling back to 152. I was having a similar issue with Google Meet. (See discussion in this other thread.)

I hypothesize that there is an issue with DTLS connections in 153. I’ve taken Wireshark traces that show that DTLS connections were not completing on 153 (they get stuck after the first response from the host on the Green subnet and then start over), but do complete with 152.

I added this Discord thread to this Bugzilla item:
https://bugzilla.ipfire.org/show_bug.cgi?id=12563

I have the share image issue with meetings but I’m newbie

I can also confirm that these problems appeared after the update with the following applications for me: Microsoft Teams, Discord, Fortnite.

I updated from core 152 to 155 today.

Here is a new application (Zoom) that I am using and the video is not working properly.

Interesting. I am running 155 and do Zoom calls on a daily basis. Firewall rules are quite strict and I have Suricata enabled for IPS. I don’t run Web Proxy.

Happy to share my settings if this will help you troubleshoot.

1 Like

I saved a discord log file with the problem, I don’t know how to interpret the log file. discord-webrtc_0.zip (12.6 KB)

Could the hardware be causing the problem? I have a Lenovo ThinkCentre M92P. I change my hardware but with the same model, but I still have the problem.

Hi @snipe,

I had a quick look at the log you attached.

Lines containing “Failed to convert device name to UTF8, error = 122” look suspicious. More of a Video / Audio codecs issue rather than IPFire hardware related.

If its just Zoom you are having issues with then you might also like to explore the Zoom Reddit or other Zoom forums for ideas on where to investigate further.

FYI… this is my hardware setup: fireinfo.ipfire.org - Profile 3dbcacf4302069328e9accd0c3731b83c9494c10

Apologies if I can’t be of any more help -or- if I’m way off the mark.

Robert

I just reinstalled ipfire again today after using OPNsense, it’s definitely IPFire. I can get video from other people, but it doesn’t get sent out to them, no matter the computer or phone on my network, discord video gets blocked. I go back to OPNsense, it works again. This is after fresh installs of both. This worked perfectly before 153 and still exists in 155.

Discord video output fails on Windows 10, Ubuntu 20.04, and Android.

I can receive other people’s video output in discord calls.

IPFire works if I use Core 152 and earlier, but after 153, it continues to not work.

I only have port forwarding to my servers. I switched to OPNsense and had no issues.

I disabled Guardian, the IPS, the QOS, basically anything not running by default. I even did fresh reinstalls. Nothing resolved. My hardware is also from a vendor through the IPFire site.

https://fireinfo.ipfire.org/profile/ee857a9c0e323acca98c8d2252102bb00a11f4f7

My hardware profile.

Hi John, I have the exact same problem as you. I upgraded IPFire to core 156 and the problems are still present.
Here is my hardware profile: fireinfo.ipfire.org - Profile 5acd41bddc17da143b4a5e6f967fc7fdcae815c7
We could compare our material.

Has anyone seen progress with 157 or 158 on this issue?

157 may be worth a try.

The info below is from the Development Mailing List posted earlier today:

(c) For quite some time, I suffered from VoIP calls not being established properly, as described in VoIP connection tracking oddities - Development - lists.ipfire.org a while ago. I unfortunately never caught the root cause for this, but blamed an error somewhere in the Linux kernel. Bug #12563 sounds pretty related.

After upgrading all IPFire machines to Core Update 157, the problem disappeared (and I was happy). Surprisingly, it reappeared at least once after having upgraded one system to Core Update 158.

Since we did not ship a kernel in C158, this rules out Linux being the sole root cause for this. I am starting to blame pppd as well, as it is the only piece of software changed in C158 that smells relevant to me. On the other hand, this would have meant we suffer from this since March 2020 at least, where we successfully updated pppd the last time (blog.ipfire.org - IPFire 2.25 - Core Update 142 released).

Anyway: I will investigate, finally try to get meaningful traces of it, and report back. I do not want to lose my functioning VoIP calls. :slight_smile:

1 Like

Hi,

yes, Core Update 157 definitely improves our behaviour in terms of fragmenting UDP packets. Please install it and report back - we are still lacking feedback on a potentially related issue, so it would be good to finally get some reports on this.

Thanks, and best regards,
Peter Müller

I tried an upgrade to 157 and subsequent upgrade to 158 to no avail. I was checking the fix with use of Teams screen share, with Cisco webex screen share and FB Messenger. I did a reload of 152 and retested with above applications and that does work. Note that Teams and webex were also over corporate VPN in both cases.

I too tried upgrading beyond 152 and have had no luck. The posted hardware profiles look to be protectcli hardware. it would be interesting to know if either some kernel driver config combination is causing this issue. I am willing to spend some time digging and providing data, but I don’t know what would be most helpful.