Description of problem: When I try to share my screen in a Webex (which uses WebRTC) conference using Firefox or Chromium, other people cannot see my screen. Screensharing does work with Google Chrome, but issue happens with various desktop environments, with both Xorg and Wayland. Using other services, like Jitsi meet, works as well. Issue goes away when I uninstall libvirt-daemon-config-network or when I ip address flush dev virbr0. Version-Release number of selected component (if applicable): libvirt-daemon-config-network-7.0.0-4.fc34 How reproducible: Happens every time, also in freshly installed VM, but my AMD-base laptop does not exhibit this problem. Steps to Reproduce: 1. Start a Webex meeting, for example on https://www.webex.com/test-meeting.html. The meeting number is accessible through cliking on the i in the top left. The password for test-meetings is test123. 2. Join the meeting on https://join-test.webex.com, either on another machine or in another browser. 3. Share screen with one of the devices. Actual results: Second device sees only grey. Expected results: Second device can see screenshare. Additional info: I realize this is probably not directly libvirt's fault, but I don't really know at which point in the chain this conflict appears. For some context, we originally talked about this problem here: https://ask.fedoraproject.org/t/share-screen-on-cisco-webex-using-firefox/13689 Hardware: (just the bits that I can imagine being relevant) i5-11400F on an AsRock H570 Phantom Gaming 4, network with an Intel Wi-Fi 6 AX200 card Relevant network interface: 5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:83:46:55 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever
When starting up a NATed network, libvirt injects some firewall rules (mostly to enable NAT). However, those should not interfere with your regular traffic. Can you please: 1) list all interfaces with their IP addresses (to see if there is no clash) 2) try turning off the default network and see if the problem persists (virsh net-destroy default).
I cannot reproduce the issue anymore. Even in a fresh (not up to date) VM with only libvirt-daemon-config-network installed, everything works. So I guess I can only wait for the problem to resurface, or not. For completeness, I can post my current network interfaces. This should be about the same to when the issue was still there, but I don't have a log. 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether [redacted] brd ff:ff:ff:ff:ff:ff 3: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether [redacted] brd ff:ff:ff:ff:ff:ff inet 192.168.178.33/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp4s0 valid_lft 863839sec preferred_lft 863839sec inet6 [redacted] scope global dynamic noprefixroute valid_lft 6720sec preferred_lft 3120sec inet6 [redacted] scope link noprefixroute valid_lft forever preferred_lft forever 4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:83:46:55 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.