Hello.
First off I want to say this issue popped up out of the blue on my laptop, after a period of not using it for several weeks. No updates or changes were made in that time. After trying unsuccessfully to solve this I decided I would just try a full reinstall for the hell of it. Now I’m booted up on a live usb and the problem persists.
I am able to connect to WIFI, but there seems to be a DNS issue.
I can successfully ping 8.8.8.8 and receive a response, but pinging google.com results in “Temporary failure in name resolution”.
Everything works fine if I connect via ethernet.
I’ve tried resetting my router to factory defaults, and disabling IPv6
my resolv.conf shows:
search hitronhub.home
nameserver 1.1.1.1
nameserver 1.0.0.1
which is what it was before this issue began.
Any ideas on how I should proceed?
Thanks
I have never had to touch resolv.conf
My resolv.conf contains my ip address and my WAN ip
Edit: These are generated by the NetworkManager.
For the record I haven’t actually changed the contents of resolv.conf, it was generated by NetworkManager. Although my desktops resolv.conf is exactly the same and works fine.
Are you using EndeavourOS?
Edit: The only reason i asked is because i have seen the resolv.conf set to this when i did an arch install. It’s not that way on my EndeavourOS install. That’s all.
Yes, however I don’t think it’s an OS related issue at all as I’ve tried an Arch USB and I’m currently on my Endeavour USB. Same issue on both.
Post the output from this command, using blockquotes ( </> symbol ) after highlighting the pasted text in post-editor:
ip addr
Using WiFi ! 
The proper way to check DNS is ping the Domain Name, Ping the IP address of the Domain and Ping your loop back address. This will tell you if it’s a DNS problem.
Edit:
Ping google.com
Ping the ip of google.com
Ping 127.0.0.1
1 Like
Here’s the output of ‘ip addr’
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: enp4s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether a8:1e:84:ad:d0:99 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3c:95:09:ca:e7:ad brd ff:ff:ff:ff:ff:ff
inet 192.168.0.20/24 brd 192.168.0.255 scope global dynamic noprefixroute wlan0
valid_lft 601256sec preferred_lft 601256sec
I keep forgetting EOS has the firewall program now. Mine is working fine.
Looks ok, no dns upstream-resolver settings seem to be in the way.
Maybe it’s a chipset issue then.
Can you post this: inxi -Fza | eos-sendlog
and then post the link here?
1 Like
Yessir, here’s the link:
https://clbin.com/akynC
Maybe add this kernel parameter to the default grub command line and update grub.
ipv6.disable=1
Edit: Then reboot
Edit2: You could also create
/etc/modprobe.d/ath10k.conf
add
options ath10k_core skip_otp=y
Edit3: Also reboot if added after
Found these links:
-
https://github.com/linux-surface/ath10k-firmware-override
sudo pacman -S linux-firmware
Say yes, to re-install.
Then:
A recent change to network manager enables wifi powersave by default, to disable this do
sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
Trying won’t hurt, as you can always undo the changes after rebooting. 
(It is just another one of these cheaper chipsets, having BT and WiFi on one chip… recurring by the day on this forum, lately.)
1 Like
Thanks for the suggestions guys. I’ve tried them all but unfortunately no dice.
However, I tried linux-lts kernel just for the hell of it, and I’m actually able to load web pages when using the lts kernel (Albeit, with extremely slow speeds). When I tried pinging google.com while using the lts kernel, it still resulted in Temporary failure in name resolution. Pinging 8.8.8.8 is successful, as before.
Like it has been said before, this is likely due to your settings in firewalld, which is not allowing for incoming pings (scroll up, please).
1 Like