5Ghz doesnt work on my machine.

seth · 2025-09-26 14:19:57

Hold on, a couple of things here don't add up.
1. "default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.135 metric 304" doesn't match some DNS server on 192.168.35.1
2. systemd-resolved doesn't actually show up in your journals, there's only iwd. Likewise in the enabled services in #5
So
1. why is there a resolved configuration if you're not using it
2.

also when changing the DNS in /run/systemd/resolve/stub-resolv.conf to 1.1.1.1 and restarting systemd-resolved with
sudo systemctl restart systemd-resolved
i get normal speeds. But after restarting the changes in /run/systemd/resolve/stub-resolv.conf disappear.

=> just enable resolved??

CST · 2025-09-27 09:46:25

I have done:

sudo systemctl start --now systemd-resolved.service

sudo systemctl enable --now systemd-resolved.service

and the speeds were still slow, but i changed the nameserver in /run/systemd/resolve/stub-resolv.conf to 1.1.1.1 and it fixed the problem, but when i restart resolved the nameserver changes again to 127.0.0.53. And they are slow again.

Last edited by CST (2025-09-27 09:48:32)

CST · 2025-09-27 10:39:52

̶N̶o̶w̶ ̶m̶y̶ ̶2̶.̶4̶g̶h̶z̶ ̶w̶i̶f̶i̶ ̶r̶a̶n̶d̶o̶m̶l̶y̶ ̶d̶i̶s̶c̶o̶n̶e̶c̶t̶s̶.̶ ̶A̶ ̶c̶l̶e̶a̶n̶ ̶i̶n̶s̶t̶a̶l̶l̶ ̶i̶s̶n̶t̶ ̶a̶ ̶b̶a̶d̶ ̶s̶o̶l̶u̶t̶i̶o̶n̶ ̶n̶o̶w̶

My bad, idk why that happened but seemed like a momentary bug, disconnected and connected again and the 2.4 is working

Last edited by CST (2025-09-27 10:58:33)

seth · 2025-09-27 12:56:51

Don't edit anything in /run, those are all transient files.
You want to set it to 1.1.1.1 in https://wiki.archlinux.org/title/System … d#Manually but apparently your (only) problem is an underdimensioned DNS server (possibly your ISPs) behind the gateway.
Since this will be a general problem in the network

I can't, im not the admin.

talk to them.

CST · 2025-09-28 10:16:02

I have a windows dualboot and the speeds go fine there, same as my phone and all my other devices, but anyways I will talk to them.

seth · 2025-09-28 14:07:33

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

However since your main problem seems the DNS server you might simply not rely on the 192.168.35.1 one (where I don't understand where this is coming from or why, assuming you've https://wiki.archlinux.org/title/System … d#Manually applied)

Setup the system as you'd normally do and when it's slow post the output of

ip a; ip r
dig archlinux.org
resolvectl status
cat /etc/systemd/resolved.conf.d/dns_servers.conf

CST · 2025-09-29 14:36:52

Can you explain it step by step a little better please?

seth · 2025-09-29 14:40:44

The lines in the square box are commands you're supposed to run and post the outputs of when the network is slow for you so we know where we're at.
dig is part of the bind package.

CST · 2025-09-29 15:58:57

ip a; ip r

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: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether f0:2f:74:d1:bc:51 brd ff:ff:ff:ff:ff:ff
    altname enxf02f74d1bc51
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 44:af:28:cf:5b:2f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.135/24 scope global dynamic noprefixroute wlan0
       valid_lft 86243sec preferred_lft 86243sec
    inet6 2a0c:5a81:3503:8200:46af:28ff:fecf:5b2f/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::46af:28ff:fecf:5b2f/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.135 metric 304 
192.168.1.0/24 dev wlan0 proto dhcp scope link metric 304

dig archlinux.org

;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out
;; communications error to 127.0.0.53#53: timed out

; <<>> DiG 9.20.13 <<>> archlinux.org
;; global options: +cmd
;; no servers could be reached

resolvectl status

Global
           Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 8.8.8.8
         DNS Servers: 1.1.1.1 8.8.8.8
Fallback DNS Servers: 9.9.9.9

Link 2 (enp5s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 4 (wlan0)
    Current Scopes: DNS LLMNR/IPv6 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 2a0c:5a80:0:2::1
       DNS Servers: 2a0c:5a80:0:2::1 2a0c:5a84:0:2::1 fe80::1
     Default Route: yes

cat /etc/systemd/resolved.conf.d/dns_servers.conf

[Resolve]
DNS=1.1.1.1

I did had connection, because I pass a speedtest (speeds were less than a mbps tho), even though archlinux.org timed out

seth · 2025-09-29 19:25:12

So the resolver (backend) is actually properly configured, but the stub listener on 127.0.0.53 (localhost) doesn't respond.

sudo nmap -sU -p 53 127.0.0.1 127.0.0.53
ss -tulpen | grep 53

https://bbs.archlinux.org/viewtopic.php?id=292291 was because of a local firewall rule…

CST · 2025-09-30 16:16:02

$ ss -tulpen | grep 53

udp   UNCONN 0      0                                0.0.0.0:5353      0.0.0.0:*           uid:976 ino:11427 sk:1 cgroup:/system.slice/systemd-resolved.service <->         
udp   UNCONN 0      0                                0.0.0.0:5355      0.0.0.0:*           uid:976 ino:11417 sk:2 cgroup:/system.slice/systemd-resolved.service <->         
udp   UNCONN 0      0                             127.0.0.54:53        0.0.0.0:*           uid:976 ino:11435 sk:3 cgroup:/system.slice/systemd-resolved.service <->         
udp   UNCONN 0      0                          127.0.0.53%lo:53        0.0.0.0:*           uid:976 ino:11433 sk:4 cgroup:/system.slice/systemd-resolved.service <->         
udp   UNCONN 0      0                                   [::]:5353         [::]:*           uid:976 ino:11428 sk:6 cgroup:/system.slice/systemd-resolved.service v6only:1 <->
udp   UNCONN 0      0                                   [::]:5355         [::]:*           uid:976 ino:11425 sk:7 cgroup:/system.slice/systemd-resolved.service v6only:1 <->
tcp   LISTEN 0      4096                             0.0.0.0:5355      0.0.0.0:*           uid:976 ino:11418 sk:a cgroup:/system.slice/systemd-resolved.service <->         
tcp   LISTEN 0      4096                          127.0.0.54:53        0.0.0.0:*           uid:976 ino:11436 sk:b cgroup:/system.slice/systemd-resolved.service <->         
tcp   LISTEN 0      4096                       127.0.0.53%lo:53        0.0.0.0:*           uid:976 ino:11434 sk:c cgroup:/system.slice/systemd-resolved.service <->         
tcp   LISTEN 0      4096                                [::]:5355         [::]:*           uid:976 ino:11426 sk:e cgroup:/system.slice/systemd-resolved.service v6only:1 <->

$ sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

$ sudo iptables -L -t nat

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

It doesnt show up the MASQUERADE thing tho.

seth · 2025-09-30 17:26:51

resolved is certainly listening.
What about the nmap output?
You still cannot

dig @127.0.0.53 archlinux.org

Can you

ping -c 1 127.0.0.53

?

CST · 2025-10-02 15:52:12

I didnt write you back because now the 5ghz connections speeds are fine so I cant test that. When it breaks again (if it does) I will answer back

seth · 2025-10-02 18:11:57

For clarification: your problem has never been the 5GHz connection but the wonky resolved behavior and/or slow DNS server at 192.168.35.1 where I don't even understand where that was coming from.

Arch Linux

#26 2025-09-26 14:19:57

Re: 5Ghz doesnt work on my machine.

#27 2025-09-27 09:46:25

Re: 5Ghz doesnt work on my machine.

#28 2025-09-27 10:39:52

Re: 5Ghz doesnt work on my machine.

#29 2025-09-27 12:56:51

Re: 5Ghz doesnt work on my machine.

#30 2025-09-28 10:16:02

Re: 5Ghz doesnt work on my machine.

#31 2025-09-28 14:07:33

Re: 5Ghz doesnt work on my machine.

#32 2025-09-29 14:36:52

Re: 5Ghz doesnt work on my machine.

#33 2025-09-29 14:40:44

Re: 5Ghz doesnt work on my machine.

#34 2025-09-29 15:58:57

Re: 5Ghz doesnt work on my machine.

#35 2025-09-29 19:25:12

Re: 5Ghz doesnt work on my machine.

#36 2025-09-30 16:16:02

Re: 5Ghz doesnt work on my machine.

#37 2025-09-30 17:26:51

Re: 5Ghz doesnt work on my machine.

#38 2025-10-02 15:52:12

Re: 5Ghz doesnt work on my machine.

#39 2025-10-02 18:11:57

Re: 5Ghz doesnt work on my machine.

Board footer