Agreed, I myself haven’t faced any problems related to audio/video on Core 153 but this may be because I did a clean install of Core 153 due to the storage device dying on me lol.
Absolutely used no backup on the fresh install because I forgot where I stored my really old backups and I’m like “I sure could use a configuration refresher” hahaha.
That said, I did uncheck everything on application-layer gateways AKA p2p protocols section i.e. H.265, Bittorrent, and etc. Not completely sure if that helps but I experience 0 problems with audio/video comms so far. (I may know Computer Networking but my experience with p2p protocols suck lol)
Maybe someone who is experiencing a problem can share a config backup file of their IPFire to help the devs diagnose this problem?
Bingo, I think this is key to this problem. Give the devs that backup of yours!
@mstriani Being new to the project, would the 154 i install today be different from the version in the testing repo from yesterday? That is how I tried 154 yesterday. I switched to the testing repo in the web interface and then did the install from 153. @sphericalumbra In parallel I am creating a diff between the backup i took of my 152 before i upgraded to 153 and the 152 i installed yesterday. I also have the 153 and 154 backups. I would like to strip my keys out of them before i do that. Any specific files i should focus on reporting?
Sad to say, today I upgraded from 152->154 and the issue is still there… I did a fresh install with the iso of 154 and still the issue… (even without the restore)
Who can help to troubleshoot this?? I’m willing to help in any way that I can, but not an expert!!!
My config is 1 GREEN 1 RED (DHCP) 1 BLUE 2 ORANGE (Bridged 2 interfaces into one zone)
Update: I’ve captured a success and failure case, with traces taken from both the Green and Red subnets each time. I’ve found that there is a difference in the fragmentation of outgoing packets between 152 and 156.
I’ve recently managed to get a Red/Green capture of a failed Google Meet session running through Core Update 156, and then rolled back to 152 to get a Red/Green capture of a successful session. Some notes:
In all cases, I set up a Meet session on my phone connected to LTE (not connected to WiFi and not going through IPFire). I then connected to that session from a PC connected to IPFire via wired Ethernet.
The fail-case symptoms I noted were slightly different from my original issue. Previously, I was unable to send or receive audio or video on the PC. This time, I was able to receive video and send audio, but was still unable to send video. This is similar to the issue I saw with Discord video chat.
I also no longer see the DTLS handshake failure. I don’t have an explanation for that - perhaps something changed on Google’s side that affected it.
The difference I’ve found between 152 and 156, is that in 156, UDP packets over a certain size (>580 bytes) are getting fragmented when traversing the firewall, whereas in 152 they are passed whole. In both cases the packets are smaller than most common MTUs, so I don’t have an explanation for the change.
I theorize that these larger packets are part of the outgoing video stream, and Google is rejecting them when fragmented. The smaller packets are likely the audio stream and are not fragmenting, thus why I can get audio out but not video.
The captures attached have again been trimmed and anonymized. Please reach out to me directly if you need the originals. I will also update the Bugzilla record.
Thanks Brian for looking at this. I too have been waiting for this to be fixed before initiating any other upgrade. I’m curious if you took a look at the adapter MTU? Did you at all run your app through a VPN and if that changed behaviour at all?
If anyone has to contribute any more data, I would be happy to hear it. So far the assumption is that this is a kernel bug, but the question is where is the bug and why is it there…
Hi Michael, IRacing was another application affected by the bug. According to “the web”, they strictly use UDP. The behavior appeared that the client lost connectivity with the server and timed out. I tried using an OpenVPN connection and the connection no longer timed out. I cannot remember if I ran the connection as UDP or TCP (last I checked the app was set to UDP).
Interesting. Obviously it would not matter what application is being used, because the kernel does not care for what is in the packets.
However, literally everyone is using video conferencing, VoIP or a VPN, and they generally work. So something must be different on the systems of the affected users.