You are not logged in.
Pages: 1
Hi everyone,
I have a problem with the university wifi (and only that one wifi, doesn't happen anywhere else... Actually, it began happening on this wifi only a few weeks back, everything worked fine 'till then), specifically a delay in the connection:
$ time ping google.com -c 1
PING google.com (142.251.209.46) 56(84) bytes of data.
--- google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m18.017s
user 0m0.002s
sys 0m0.003sI can eventually reach the pages, but it takes something like 30 seconds or more for them to actually start loading (and then they load almost immediately 'cause the wifi has a fast 400Mb/s bitrate)
Useful informations:
$ lspci | grep -i net
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device b852
$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
ananicy-cpp.service | local-fs.target.wants
bluetooth.service | bluetooth.target.wants
dbus-org.bluez.service | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service | system
display-manager.service | system
gcr-ssh-agent.socket | sockets.target.wants
getty@tty1.service | getty.target.wants
irqbalance.service | multi-user.target.wants
laptop-mode.service | multi-user.target.wants
memavaild.service | multi-user.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
nohang.service | multi-user.target.wants
p11-kit-server.socket | sockets.target.wants
pipewire.socket | sockets.target.wants
preload.service | multi-user.target.wants
prelockd.service | multi-user.target.wants
pulseaudio.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-timesyncd.service | sysinit.target.wants
uresourced.service | user@.service.wants
xdg-user-dirs-update.service | default.target.wants
$ ip a
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: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9c:2f:9d:63:9d:cb brd ff:ff:ff:ff:ff:ff
inet 10.169.169.141/24 brd 10.169.169.255 scope global dynamic noprefixroute wlp3s0
valid_lft 423sec preferred_lft 423sec
inet6 fe80::af84:8a81:75dd:f32c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip r
default via 10.169.169.254 dev wlp3s0 proto dhcp src 10.169.169.141 metric 600
10.169.169.0/24 dev wlp3s0 proto kernel scope link src 10.169.169.141 metric 600
$ dig google.com
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.8.8#53: timed out
;; communications error to 8.8.4.4#53: timed out
; <<>> DiG 9.18.19 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42473
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 873 IN A 142.251.209.46
;; Query time: 3 msec
;; SERVER: 172.25.1.1#53(172.25.1.1) (UDP)
;; WHEN: Wed Nov 15 08:49:44 CET 2023
;; MSG SIZE rcvd: 55
$ tracepath -b google.com
1?: [LOCALHOST] pmtu 1476
1: _gateway (10.169.169.254) 1.081ms
1: _gateway (10.169.169.254) 1.008ms
2: 10.169.174.169 (10.169.174.169) 3.436ms
3: 10.169.174.77 (10.169.174.77) 3.640ms asymm 4
4: no reply
5: no reply
6: no reply
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1476
Resume: pmtu 1476 Last edited by Achille0072 (2023-11-16 12:42:33)
Offline
Looks like your university is blocking DNS queries to 8.8.x.x and the fallback/timeout takes a while to kick in.
Offline
Looks like your university is blocking DNS queries to 8.8.x.x and the fallback/timeout takes a while to kick in.
Yes, it seems you are right. The delay disappeared once I completely removed 8.8.8.8 and 8.8.4.4 from the "additional dns servers" section in the network configuration
How can I mark this thread as SOLVED?
Last edited by Achille0072 (2023-11-16 12:41:43)
Offline
Pages: 1