Fedora takes crucial part in the supply chain of this component by installing it as a preferred hard dependency for GNOME and KDE on first update.
This leads to additional regional restrictions enforced with GeoIP filtering and sometimes affecting unrelated regions.
The original intention may have been good, but the current result is a significant blow to the “100% free” motto.
I believe that disabling the Cisco repo by default would be a reasonable solution.
You can technically do everything else a computer can do without involving a video codec (songs, art, reading, web browsing, games; a lot of choices beyond something like YT videos 
)
I suggest you to try cleaning your package cache, forcing a cache refresh, and then disabling the problematic Cisco openh264 repository :
sudo dnf clean all
sudo dnf makecache
sudo dnf config-manager setopt fedora-cisco-openh264.enabled=0
sudo dnf update
Once, update successful just re-enable the Cisco OpenH264 repository:
sudo dnf config-manager setopt fedora-cisco-openh264.enabled=1
Thanks for your comment, but the issue has been solved already.
I have created the script that disables the repo and installs all multimedia codecs.
It updates fine now, the 403 error is gone.
Thanks for the update
good point! I’m not used to this concept yet.
let me summarize the solution:
I have created a bilingual script (russian/english) that disables Cisco openh264 dependencies to ensure both dnf and flatpak updates work again in affected regions without the need of any VPN.
to make sure this does not affect video playback, the script installs all necessary video codecs (including non-free ones) except Vulkan video (which i will add in the next version).
the script handles Intel/AMD platforms and DNF (classic)/Ostree (atomic) Fedora variants starting from Fedora 40 and newer.
as the process is completely automated, this script can be used after initial (“clean”) Fedora installation by everyone to install necessary multimedia codecs, even if you are not affected by the 403 geoblock.
the script is idempotent and can be rerun many times if any parts fail for any reason. Initial system update can take some time, don’t interrupt the script, it handles errors and will not “hang”.
users can directly run the script from the terminal:
curl -sSL https://raw.githubusercontent.com/supertico/fedora-open264-geoblock-fix/main/fedora-cisco-403-mitigation.sh | sudo bash
detailed info & screenshots available on github:
I have Intel UHD 630, and YouTube on Firefox can hardware-accelerate with OpenH264 disabled under about:addons → Plugins. No RPM Fusion F43 Workstation:
Anyone have a link to something I can try for acceleration checking?
Your screen shows that YouTube uses VP9 codec, so H264 is not touched in this case.
I’ll just leave this here…
Hi Anatoli,
it seems that the 403 error in our countries is here to stay for a long time ((
could you mark the message with the current solution (my script disabling the notorious cisco codec) as the solution in this forum, so that affected people could find it easier? I’m unable to do it myself as you are the topic starter.
I wish that Fedora came with better and more “official” option, but this world is not perfect and that’s what we have at the moment.
With much respect, I disagree with marking a script as the ‘solution’.
The few simple command lines to disable the repo are the raw solution, and have been provided multiple times in the thread.
well, if you disable the repo the cisco codec won’t even be installed on fresh installs, what about making sure the videos play?
then you have to care about flatpaks too, their update process breaks too.
if you have silverblue the lines are different.
so it’s not about “few simple lines” already 
wondering if the problem with the geoblock has affected you personally? you obviously don’t live in the countries affected and probably don’t understand how painful it is when whole your update process fails and you suddenly have to dig in the internet looking for what to do and how to fix it (especially upsetting if you needed to install a program and it won’t either). Issues like this arise in this region every week now and people constantly have to look for new solutions and waste their time instead of just living their lives.
the script fixes the issue that Fedora doesn’t currently want to fix (while it absolutely can, and should!) with running 1 single command, and also fixes the codec dependencies which are required as an alternative, it’s the easiest solution at the moment. We have to do it on each fresh install/reinstall.
of course you can force users to do all this manually, but why, when it can (and is) perfectly automated with the script already? When I faced the geoblock myself, i was surprised to find out that nobody has created such a script already.
I believe @theprogram meant that, while yours is a solution, it’s not the solution. If so, I agree with him. (Especially about VLC, lol.)
The solution would have to come from the Fedora Project, and there’s nothing on the horizon so far.
Incidentally, let’s try and not bring extra negativity here… This world has too much of it already.
It is more about global politics and sanctions against certain countries, which RedHat or Fedora can do very little about.
They could at least warn users from the affected regions the software is unupdatable and unusable.
As far as I can tell, Cisco are either grossly misinterpreting the EAR (Russia isn’t on the list, let alone Kyiv), or inventing their own “sanctions” outright. And, as I mentioned earlier, it’s not the first time that happens.
And yes, the Fedora Project could solve this issue – for example, by simply asking the user if they want or need to enable OpenH264 during the OS installation. As I’ve pointed out on Pagure, the current approach is an example of US defaultism.
Hmm..
I don’t agree with this interpretation.
I think the what we are seeing is one example of a problem in how dnf clients deal with a general class of network disruption cornercases that are possible when package level HTTP redirects inside an rpm repository structure are used. This class of cornercases were not anticipated when designing the clientside dnf dependency resolver.
The noopenh264 package does exist, and is intended to provide an rpm dependency requirement fallback when the openh264 package isn’t available at install time. This fallback works as intended when the codec repo metadata is unreachable, but doesn’t work as intended when the HTTP redirects at the package level fail.
The key point here to the failure is that the repo metadata and the packages are hosted on separate servers. Anytime that happens and package level HTTP redirects are used to make it appear like the packages are on the same server as the metadata, this creates the potential where the client can pull the metadata but can’t pull the packages, in a later step, due to a variety of network disruptions outside the control of the client admin to solve.
The technical problem on the clientside is the order of operations doesn’t anticipate the existence of package level HTTP redirects in a way that makes it possible to recover by rerunning the dep resolution transaction again with the enabled repos modified to exclude the repo using broken HTTP redirects.
You don’t have to get into questions of defaultism, I can and have recreated the problem using a misconfigured local DNS server that blackholes the the DNS name of the cisco server holding the packages. The repository metadata is held on a server in fedoraproject DNS domain and HTTP redirects are used for the packages hosted in the cisco domain. If I blackhole the fedoraproject server, the fallback works as intended. If I blackhole the cisco server, it doesn’t. When the fedoraproject codec server is reachable the clientside dep resolution is able pull the metadata and do the dep resolution and then bails trying to download the packages (via the redirects to a server it can’t access) when it runs out of mirrors to try (because there are no mirrors).
To fully handle the class of problems associated with package level HTTP redirects, the client logic would have to be extended. For example, I can imagine adding a new conditional loop to throw away the entire rpm transaction, do a soft disable on the repos that are failing to pull packages and running out of mirrors to try, and redo the dep resolution and rebuild the transaction to attempt with a different set of enabled repos, resulting in a potentially different set of packages. Basically, a retry loop using a modified enabled repo set. The client already has conditional logic to drop the repo if the metadata can’t be reached on the first pass at doing the dep resolution. What I’m talking about is adding a second pass, informed by the failures of the HTTP redirect failures during the first attempt.
What videos? If YouTube can do VP9, can’t every GPU either use that or fallback to software?
Well, that’s just the impression I’ve got after following RHBZ and Pagure tickets on the matter, where OpenH264 is often presented as something essential. I certainly wouldn’t mind to be proven wrong, though!
That aside, thank you for the in-depth investigation. I think addressing this here corner case could end up being beneficial for dnf in the long run. Incidentally, I’m still subscribed to RHBZ #2397163, but if this ever gets a separate ticket filed, please let us know.
The GPU is not the issue. It is the codecs that are not available directly from fedora.
The h264 codecs from the cisco repo are the ones that at present are responsible for this issue, and AFAIK the only other readily available source for similar codecs is the rpmfusion repos with packages such as x264, x265, libavcodec-freeworld and the like.
Firefox depends on the mozilla-openh264 package so without that from the cisco repo it presents a problem. I have exactly 2 packages installed from the fedora-cisco-openh264 repo openh264 & mozilla-openh264
It would seem that if firefox did not require mozilla-openh264 (which then requires openh264) the problem could readily be solved. Maybe make another browser the default for fedora?
