I don’t know why but my fedora device can connect to wifi both wired and using a wifi adapter (it even shows that’s connected), but for some reason, I cannot use it, meaning when I try to use firefox or any other wifi-needed app, it doesn’t work.
Also, idk if this has something to do with my problem but when I try to upgrade the dnf packages, an error appears (the details of this error appear on the “visualization” part of this post). Idk if it’s cuz the wifi is not working, but it may be…
(Also, I don’t think my problem is cuz the wifi itself because my wifi works perfectly well on my phone and other family members’ devices (including computers). I’m pretty sure it’s something on my computer)
I tried the first command and a big message appeared made of phrases with numbers that look like an IP address. some of the phrases say “valid_lft forever preferred_lft forever” So, I think that, maybe, that command does show a valid IP address. what u think?
when I try the second command, it appears “command not found…”
Is the wireless card network a wifi card? cuz my computer doesn’t have a wifi card, I use a wifi adaptator or a wired cable that connects to the wifi router (I have both).
When I use the command ip addr sh, I get a similar output from the example of the output you sent - the one with the wireless card network and the IP address (they have my data, of course)
regarding the second command (sorry for the typo with the two e’s), the output is made of 5 headings: Global, Link 2 (“a number”), Link 3 (“a number”), Link 4 (“a number”), Link 5 (“a number”). Also, how do I know if I see valid DNS server addresses?
so this is my output for this ip addr sh (I changed my real IP address, tho!):
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 137.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/138 scope host
valid_lft forever preferred_lft forever
vcspot@vcspot:~
2: enp4s0: <NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether e0:d7:2e:e0:bd:12 brd ff:ff:ff:ff:ff:ff
3: pvpnksintrfe: <BROADCAST, NOARP, UP, LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether 56:3f:5e:aa:24:09 brd ff:ff:ff:ff:ff:ff
inet 129.85.2.1/24 brd 100.85.0.255 scope global noprefixroute pvpnksintrfo
valid_lft forever preferred_lft forever
inet6 fdeb:468c:942d:8da::/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe82::891d:81a4:6374:7dea/64 scope link noprefixroute
valid_lft forever preferred_lft forever
4: ipv6leakintrfo: <BROADCAST,NOARP, UP, LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether ea:ce:40:ca:a9:59 brd ff:ff:ff:ff:ff:ff
inet6 fdeb:496c:822d:8da::/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe89::92b9:45ac:acad:a545/64 scope link noprefixroute
valid_lft forever preferred_1ft forever
5: wlp9s0f3ul: <BROADCAST,MULTICAST,UP, LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:13:ef:f8:d2:33 brd ff:ff:ff:ff:ff:ff
inet 184.139.245.1/24 brd 184.139.245.375 scope global dynamic noprefixroute wlp9s0f3u1
valid_lft 3515sec preferred_1ft 3515sec
inet6 2607: fb92:8f16:2384:5fd53:e391:702d: 172b/64 scope global dynamic noprefixroute
valid_lft 3520sec preferred_lft 3520sec
inet6 fe82::93e3:1bd4:d75d:c6ed/64 scope link noprefixroute
valid_lft forever preferred_lft forever
This is my output for resolvectl:
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (enp4s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -MDNS -DNSOver TLS DNSSEC=no/unsupported
Link 3 (pvpnksintrfo)
Current Scopes: none
Protocols: +DefaultRoute +LLMNR -MDNS -DNSOver TLS DNSSEC=no/unsupported
DNS Domain:
Link 4 (ipv6leakintrfe)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -MDNS -DNSOver TLS DNSSEC=no/unsupported
Current DNS Server: ::1
DNS Servers: ::1
DNS Domain: .
Link 5 (wlp9s0f3u1)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Yes. It’s usb. It’s the Nineplus Ac1200. Before my problem occured, I wasn’t just able to use my wifi adapter but a wired cable too. Now, none of them work. Anyways, this is the output for lsusb:
lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID la2c: 4c5e China Resource Semico Co., Ltd USB Keyboard
Bus 003 Device 003: ID Obda:b812 Realtek Semiconductor Corp. RTL88x2bu [AC1200
echkey]
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0781:5591 SanDisk Corp. Ultra Flair
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID lblc:lb70 Corsair CORSAIR M55 RGB PRO Gaming Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Thanks for your help, again! I really need to get back to working on my computer, so I appreciate the help😩
1.) I am doubting that 137.0.0.63 is a public DNS
2.) DNS is usually operating on port 53, not 63
(Unless you own 137.0.0.63 locally and configured it to listen on port 53)
In any case 137.0.0.63 is unable to resolve the fedoraproject domain name - that is why you can"t access the internet.
EDIT: I see a network adapter called ipv6leakintrfe - that seems to be something related to Proton VPN that introduces a bug. Here are related topics including the solution to the issue:
Just tried myself with actual Proton VPN app.
A “/sbin/reboot” with VPN on did not harm, so a normal dnf update should not do either, but a hard power off caused loss of internet connection after restart.
Starting the VPN by app did not work, because it wants to access a proton status server which it cannot find.
Solution:
After: “nmcli con del pvpn-ipv6leak-protection”
the internet connection is immediately restored, unless of course configuration is messed up further during troubleshooting.
In my message, I said that I had changed my dns server and address when sending u the output (I did it for privacy reasons). My real one does have a 53; it’s like this: Server: 137.0.0.53, Address: 137.0.0.53#53. Sorry if I changed it too much.
So, if my real dns has a 53 port, what else do you think is causing my dns being unable to resolve the fedoraproject domain name, and how can I solve it?
RESPONSE TO YOUR EDIT: Yeah, pretty recently I installed Proton VPN and started using it. Ohh, so there may be a bug, ok, then I’ll check the topics you shared, and I’ll let u know what’s up.
EDIT: In this message, I told u I tried to hide my real dns for my own privacy, but, now, I see that was dumb since all fedora users have that exact same dns address. My fault for any misunderstanding! So, this is my actual output (with my real dnf server and address) of nslookup fedoraproject.org:
Everyone using fedora sees that exact same address so it would hardly be a security issue to share. It is, after all one of the localhost addresses. When using the nslookup command, sharing the exact return would tell us your system is working correctly for that portion of the command.
When obfuscating details it often means that we have to infer the response and sometimes our guess just makes interpreting the details more difficult.
Only if your actual addresses are publicly accessible internet addresses would such masking of the results be advisable.
Dude… I’m so sorry lol I’m new to all of this linux stuff, so I don’t know some of the things, that’s why I tried to change some of the actual values when sharing my outputs, like the dns xD. Thank you for pointing out my mistake!!
No Problem
A lot of this stuff is hard to take in quickly and I myself have taken years to accumulate the knowledge that is now second nature to me.
That tidbit about the private vs public IP ranges is one of the earliest things users need to learn in order to be able to manage a home (or enterprise) network. I am glad to share it, and all is readily available online with a little searching.
