Sudden DNS issue (wifi only)

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 ! :wink:

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

Beware of the Firewall!

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:

  1. 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. :wink:

(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