Problems doing a system upgrade (packages & cannot find repoitory issue: openh264)

My output is:

[fedora-cisco-openh264]
name=Fedora $releasever openh264 (From Cisco) - $basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-$releasever&arch=$basearch
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True

[fedora-cisco-openh264-debuginfo]
name=Fedora $releasever openh264 (From Cisco) - $basearch - Debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-cisco-openh264-debug-$releasever&arch=$basearch
type=rpm
enabled=1
metadata_expire=14d
repo_gpgcheck=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=True

The first step should be to confirm that the network is properly connected to the gateway.

The interface names can be clearly seen with the command ip address as shown below.
Yours will likely be different, but the one of interest is the one you use to connect to the internet.
Is it wifi? If so, have you already connected it to the access point? If not connected then do so.
If using ethernet probably nothing else will need to be done.

$ ip address
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 noprefixroute 
       valid_lft forever preferred_lft forever
2: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 9c:6b:00:12:f2:43 brd ff:ff:ff:ff:ff:ff
3: wlp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 44:af:28:56:ec:12 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.113/22 brd 192.168.7.255 scope global dynamic noprefixroute wlp5s0
       valid_lft 13439sec preferred_lft 13439sec

Note that my ethernet port (enp6s0) is not connected.
My wifi port (wlp5s0) is connected, up, and has an assigned IP of 192.168.4.113. (seen as inet 192.168.4.113/22)

Using ip route I can see the routing

$ ip route
default via 192.168.4.1 dev wlp5s0 proto dhcp src 192.168.4.113 metric 600 
192.168.4.0/22 dev wlp5s0 proto kernel scope link src 192.168.4.113 metric 600 

In my case the gateway is at 192.168.4.1 via device wlp5s0. Once you can see that info a simple ping to the gateway will confirm connectivity using ping -c 5 192.168.4.1 to send 5 pings and see the response.

Of course your IP addresses and device names are likely different. If using ethernet and not wifi it should show an address on the wired interface instead.

% dig ciscobinary.openh264.org

; <<>> DiG 9.18.24 <<>> ciscobinary.openh264.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16058
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ciscobinary.openh264.org.      IN      A

;; ANSWER SECTION:
ciscobinary.openh264.org. 82703 IN      CNAME   a21ed24aedde648804e7-228765c84088fef4ff5e70f2710398e9.r17.cf1.rackcdn.com.
a21ed24aedde648804e7-228765c84088fef4ff5e70f2710398e9.r17.cf1.rackcdn.com. 300 IN CNAME a17.rackcdn.com.
a17.rackcdn.com.        300     IN      CNAME   a17.rackcdn.com.mdc.edgesuite.net.
a17.rackcdn.com.mdc.edgesuite.net. 300 IN CNAME a19.dscg10.akamai.net.
a19.dscg10.akamai.net.  20      IN      A       142.176.208.208
a19.dscg10.akamai.net.  20      IN      A       142.176.208.200

;; Query time: 161 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Sun Mar 17 19:33:48 ADT 2024
;; MSG SIZE  rcvd: 269

So https://ciscobinary.openh264.org/ is on akamai.net. If I put the ciscobinary URL in firefox,I get a warning page:

What can you do about it?

The issue is most likely with the website, and there is nothing you can do to resolve it. You can notify the website’s administrator about the problem.

The “Advanced” button adds:

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for ciscobinary.openh264.org. The certificate is only valid for the following names: a248.e.akamai.net, *.akamaized.net, *.akamaized-staging.net, *.akamaihd.net, *.akamaihd-staging.net

Error code: SSL_ERROR_BAD_CERT_DOMAIN

3 Likes

This is a bit strange. Here in Europe, the cisco packages are downloaded from
https://codecs.fedoraproject.org/openh264/39/x86_64/os/repodata/repomd.xml

which resolves as

codecs.fedoraproject.org. 300	IN	CNAME	wildcard.fedoraproject.org.
wildcard.fedoraproject.org. 60	IN	A	8.43.85.67
wildcard.fedoraproject.org. 60	IN	A	8.43.85.73
wildcard.fedoraproject.org. 60	IN	A	34.221.3.152
wildcard.fedoraproject.org. 60	IN	A	38.145.60.20
wildcard.fedoraproject.org. 60	IN	A	38.145.60.21
wildcard.fedoraproject.org. 60	IN	A	67.219.144.68
wildcard.fedoraproject.org. 60	IN	A	140.211.169.196
wildcard.fedoraproject.org. 60	IN	A	152.19.134.142
wildcard.fedoraproject.org. 60	IN	A	152.19.134.198

can you post:
sudo dnf -v repolist --enabled | grep -E '^(Repo-name|Repo-baseurl)'

Thanks

Alright, so if https://ciscobinary.openh264.org/ gives me a warning page, which website do I have to go to to report this problem to fix it? Sorry if this is a stupid question, this is the first time I have dealt with a mirror not connecting to a server that’s all.

You haven’t provided enough information for us to understand why you get the broken http://ciscobinary.openh264.org/ URL. The first step would be to show us the URL dnf generates as requested:

Here, I get:

Repo-name          : Fedora 39 openh264 (From Cisco) - x86_64
Repo-baseurl       : https://codecs.fedoraproject.org/openh264/39/x86_64/os/ (0 more)
2 Likes
Last metadata expiration check: 0:17:14 ago on Sun 31 Mar 2024 19:09:53.
Repo-name          : MEGAsync
Repo-baseurl       : https://mega.nz/linux/repo/Fedora_39/
Repo-name          : created by dnf config-manager from https://brave-browser-rpm-release.s3.brave.com/x86_64/
Repo-baseurl       : https://brave-browser-rpm-release.s3.brave.com/x86_64/
Repo-name          : Visual Studio Code
Repo-baseurl       : https://packages.microsoft.com/yumrepos/vscode
Repo-name          : Copr repo for g810-led owned by lkiesow
Repo-baseurl       : https://download.copr.fedorainfracloud.org/results/lkiesow/g810-led/fedora-39-x86_64/
Repo-name          : Copr repo for soundux owned by rivenirvana
Repo-baseurl       : https://download.copr.fedorainfracloud.org/results/rivenirvana/soundux/fedora-39-x86_64/
Repo-name          : Crystal (Fedora_37)
Repo-baseurl       : https://download.opensuse.org/repositories/devel:languages:crystal/Fedora_37/
Repo-name          : Fedora 39 - x86_64
Repo-baseurl       : https://gsl-syd.mm.fcix.net/fedora/linux/releases/39/Everything/x86_64/os/ (18 more)
Repo-name          : Fedora 39 openh264 (From Cisco) - x86_64
Repo-baseurl       : https://codecs.fedoraproject.org/openh264/39/x86_64/os/ (0 more)
Repo-name          : Fedora 39 openh264 (From Cisco) - x86_64 - Debug
Repo-baseurl       : https://codecs.fedoraproject.org/openh264/39/x86_64/debug/tree/ (0 more)
Repo-name          : RPM Fusion for Fedora 39 - Free
Repo-baseurl       : http://ucmirror.canterbury.ac.nz/linux/rpmfusion/free/fedora/releases/39/Everything/x86_64/os/ (59 more)
Repo-name          : RPM Fusion for Fedora 39 - Free - Updates
Repo-baseurl       : http://ucmirror.canterbury.ac.nz/linux/rpmfusion/free/fedora/updates/39/x86_64/ (57 more)
Repo-name          : RPM Fusion for Fedora 39 - Nonfree
Repo-baseurl       : rsync://gsl-syd.mm.fcix.net/rpmfusion/nonfree/fedora/releases/39/Everything/x86_64/os/ (82 more)
Repo-name          : RPM Fusion for Fedora 39 - Nonfree - Updates
Repo-baseurl       : rsync://gsl-syd.mm.fcix.net/rpmfusion/nonfree/fedora/updates/39/x86_64/ (81 more)
Repo-name          : Fedora 39 - x86_64 - Updates
Repo-baseurl       : https://gsl-syd.mm.fcix.net/fedora/linux/updates/39/Everything/x86_64/ (260 more)

Repo-name          : Fedora 39 openh264 (From Cisco) - x86_64
Repo-baseurl       : https://codecs.fedoraproject.org/openh264/39/x86_64/os/ (0 more)

Looks fine. Does a browser open this URL and can you navigate to Packages.o? Here

Index of /openh264/39/x86_64/os/Packages/o
[ICO]	Name	Last modified	Size	Description
[PARENTDIR]	Parent Directory	 	- 	 
[ ]	openh264-2.3.1-2.fc39.x86_64.rpm	2023-03-13 20:05 	420K	RPM Package
[ ]	openh264-2.4.0-2.fc39.x86_64.rpm	2023-12-12 17:33 	421K	RPM Package
[ ]	openh264-devel-2.3.1-2.fc39.x86_64.rpm	2023-03-13 20:05 	24K	RPM Package
[ ]	openh264-devel-2.4.0-2.fc39.x86_64.rpm	2023-12-12 17:33 	24K	RPM Package
Apache Server at codecs.fedoraproject.org Port 443
1 Like

Yes. The Index of /openh264/39/x86_64/os shows me Packages/ then o/. It shows:

[ ] openh264-2.3.1-2.fc39.x86_64.rpm 2023-03-13 20:05 420K RPM Package
[ ] openh264-2.4.0-2.fc39.x86_64.rpm 2023-12-12 17:33 421K RPM Package
[ ] openh264-devel-2.3.1-2.fc39.x86_64.rpm 2023-03-13 20:05 24K RPM Package
[ ] openh264-devel-2.4.0-2.fc39.x86_64.rpm 2023-12-12 17:33 24K RPM Package

To be clear, it’s perfectly normal that the file is being downloaded from ciscobinary.openh264.org, That’s part of the rigamarole that makes openh264 legal to use:

$ curl https://codecs.fedoraproject.org/openh264/39/x86_64/os/Packages/o/openh264-2.4.0-2.fc39.x86_64.rpm
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="http://ciscobinary.openh264.org/openh264-2.4.0-2.fc39.x86_64.rpm">here</a>.</p>
<hr>
<address>Apache Server at codecs.fedoraproject.org Port 443</address>
</body></html>

I have no idea why you can’t connect to Cisco’s servers though.

I’ve also gotten some help from someone else who stated they fixed the issue, they’ve stated that the repo is out of sync for fedora-cisco-openh264 or something like that.

I’ve also found that I was able to get some of the packages downloaded by using a VPN. Could the openh264 repo be blocked or blacklisted by my ISP possibly?

If downloads work for Fedora users in the location used by the VPN they should work for you. Are you have problems with other packages other than openh264?

Currently that is the only one. I have used a VPN & swapped to some different IP addresses & it seemed to fix the problem. I don’t know why changing IP addresses fixed the problem with allowing the repos to be downloaded, but it did. I guess I will mark this current comment as the solved comment.

2 Likes