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
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
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:
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.
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] json-c-0.17-3.fc40.i686.rpm: Already downloaded
[SKIPPED] libdecor-0.2.2-3.fc40.i686.rpm: Already downloaded
[SKIPPED] libjaylink-0.3.0-5.fc40.x86_64.rpm: Already downloaded
[SKIPPED] libnma-gtk4-1.10.6-7.fc40.x86_64.rpm: Already downloaded
[SKIPPED] patch-2.7.6-24.fc40.x86_64.rpm: Already downloaded
[SKIPPED] NetworkManager-libreswan-gnome-1.2.24-1.fc40.x86_64.rpm: Already downloaded
[SKIPPED] SDL2-2.30.9-1.fc40.i686.rpm: Already downloaded
[SKIPPED] kdump-utils-1.0.48-1.fc40.x86_64.rpm: Already downloaded
[SKIPPED] kernel-6.12.7-100.fc40.x86_64.rpm: Already downloaded
[MIRROR] mozilla-openh264-2.4.1-2.fc40.x86_64.rpm: Status code: 404 for http://ciscobinary.openh264.org/mozilla-openh264-2.4.1-2.fc40.x86_64.rpm/ (IP: 23.46.228.6)
[MIRROR] mozilla-openh264-2.4.1-2.fc40.x86_64.rpm: Status code: 404 for http://ciscobinary.openh264.org/mozilla-openh264-2.4.1-2.fc40.x86_64.rpm/ (IP: 23.46.228.6)
[MIRROR] mozilla-openh264-2.4.1-2.fc40.x86_64.rpm: Status code: 404 for http://ciscobinary.openh264.org/mozilla-openh264-2.4.1-2.fc40.x86_64.rpm/ (IP: 23.46.228.6)
[MIRROR] mozilla-openh264-2.4.1-2.fc40.x86_64.rpm: Status code: 404 for http://ciscobinary.openh264.org/mozilla-openh264-2.4.1-2.fc40.x86_64.rpm/ (IP: 23.46.228.6)
[FAILED] mozilla-openh264-2.4.1-2.fc40.x86_64.rpm: No more mirrors to try - All mirrors were already tried without success
(11-12/1219): kernel-core-6.12.7-100.fc40.x86_64.rpm 0% [ ] 3.5 MB/s | 18 MB 10:47 ETA
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Error downloading packages:
mozilla-openh264-2.4.1-2.fc40.x86_64: Cannot download, all mirrors were already tried without success
I installed the package with rpm -i and then retried dnf update, which worked without error.
I also sent the URL without trailing slash to my phone and opened it in the browser. The package downloaded without issue.
EDIT: Also just hit this on a clean offline install of F41 upon its first attempt to update. Same workaround works; remove the trailing slash from the URL that DNF reports as a 404 error and open it in a browser, then install the package that gets downloaded.