Can't connect via ethernet after update

darkghost568 · 2018-11-24 03:25:58

Hey guys,

So I update my Arch system just about every day, and yesterday's update messed up my ethernet connection. A LOT of packages were updated, so I'm not sure which is the culprit. Here's the outputs of commands that seemed relevant after reading the wiki and Google searching:

 [david@archPC ~]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 54:a0:50:d5:1c:af brd ff:ff:ff:ff:ff:ff
3: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 40:e2:30:85:b9:81 brd ff:ff:ff:ff:ff:ff
[david@archPC ~]$ ping [url=http://www.google.com]www.google.com[/url]                      
ping: [url=http://www.google.com]www.google.com[/url]: Temporary failure in name resolution
[david@archPC ~]$ sudo systemctl start dhcpcd@eno1.service 
[sudo] password for david: 
Job for dhcpcd@eno1.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status dhcpcd@eno1.service" and "journalctl -xe" for details.
[david@archPC ~]$ sudo systemctl status dhcpcd@eno1.service 
● dhcpcd@eno1.service - dhcpcd on eno1
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset:>
   Active: failed (Result: protocol) since Fri 2018-11-23 17:55:55 EST; 5s ago
  Process: 1404 ExecStart=/usr/bin/dhcpcd -q -w eno1 (code=exited, status=0/SUCCESS)

Nov 23 17:55:55 archPC systemd[1]: Starting dhcpcd on eno1...
Nov 23 17:55:55 archPC dhcpcd[1404]: sending commands to master dhcpcd process
Nov 23 17:55:55 archPC systemd[1]: dhcpcd@eno1.service: Can't open PID file /run/dh>
Nov 23 17:55:55 archPC systemd[1]: dhcpcd@eno1.service: Failed with result 'protoco>
Nov 23 17:55:55 archPC systemd[1]: Failed to start dhcpcd on eno1.

Any help would be appreciated!

Last edited by darkghost568 (2018-11-24 04:07:28)

jasonwryan · 2018-11-24 03:39:20

Don't post images of text, paste the actual text.

How do you normally manage your network? Paste, in code tags, the output of `systemctl list-unit-files --state=enabled`.

darkghost568 · 2018-11-24 04:10:27

jasonwryan wrote:

Don't post images of text, paste the actual text.
How do you normally manage your network? Paste, in code tags, the output of `systemctl list-unit-files --state=enabled`.

Got it, sorry about that. Updated the OP. I'm actually on University ethernet, so I'm not the one managing the network. I haven't had a problem with ethernet until yesterday's update. Here's the output:

[david@archPC ~]$ systemctl list-unit-files --state=enabled
UNIT FILE                   STATE  
autovt@.service             enabled
dhcpcd.service              enabled
getty@.service              enabled
nvidia-persistenced.service enabled
systemd-timesyncd.service   enabled
remote-fs.target            enabled

6 unit files listed.
[david@archPC ~]$

Last edited by darkghost568 (2018-11-24 04:18:18)

jasonwryan · 2018-11-24 04:18:00

So you have the daemon running for all interfaces, which is why it couldn't start the specific one:
https://wiki.archlinux.org/index.php/Dhcpcd#Running

darkghost568 · 2018-11-24 04:33:54

jasonwryan wrote:

So you have the daemon running for all interfaces, which is why it couldn't start the specific one:
https://wiki.archlinux.org/index.php/Dhcpcd#Running

Forgive me since I'm still very noob. Here's what I ran:

[david@archPC ~]$ sudo systemctl stop dhcpcd.service
[sudo] password for david: 
[david@archPC ~]$ sudo systemctl disable dhcpcd.service
Removed /etc/systemd/system/multi-user.target.wants/dhcpcd.service.
[david@archPC ~]$ sudo systemctl enable dhcpcd@eno1.service
[david@archPC ~]$ sudo systemctl start dhcpcd@eno1.service
[david@archPC ~]$ sudo dhcpcd eno1
DUID 00:04:03:00:02:00:04:00:05:00:00:06:00:07:00:08:00:09
eno1: IAID 50:d5:1c:af
eno1: soliciting an IPv6 router
eno1: rebinding lease of 172.19.93.115
eno1: leased 172.19.93.115 for 120 seconds
eno1: adding route to 172.19.93.0/24
eno1: adding default route via 172.19.93.1
forked to background, child pid 1153
[david@archPC ~]$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution
[david@archPC ~]$

jasonwryan · 2018-11-24 04:38:31

Don't run dhcpcd manually after you enable/start the service: that will just result in a conflict. Read the wiki page: it says Alternatively...

darkghost568 · 2018-11-24 04:58:15

jasonwryan wrote:

Don't run dhcpcd manually after you enable/start the service: that will just result in a conflict. Read the wiki page: it says Alternatively...

Ok, I rebooted and ran this:

[david@archPC ~]$ sudo systemctl stop dhcpcd.service
[david@archPC ~]$ sudo systemctl disable dhcpcd.service
[david@archPC ~]$ sudo systemctl enable dhcpcd@eno1.service  
[sudo] password for david: 
[david@archPC ~]$ sudo systemctl start dhcpcd@eno1.service 
[david@archPC ~]$ sudo systemctl status dhcpcd@eno1.service
● dhcpcd@eno1.service - dhcpcd on eno1
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled; vendor preset:>
   Active: active (running) since Fri 2018-11-23 18:49:17 EST; 1min 45s ago
 Main PID: 683 (dhcpcd)
    Tasks: 1 (limit: 4915)
   Memory: 5.9M
   CGroup: /system.slice/system-dhcpcd.slice/dhcpcd@eno1.service
           └─683 /usr/bin/dhcpcd -q -w eno1

Nov 23 18:48:50 archPC dhcpcd[590]: eno1: soliciting a DHCP lease
Nov 23 18:48:50 archPC dhcpcd[590]: eno1: soliciting an IPv6 router
Nov 23 18:49:04 archPC dhcpcd[590]: eno1: no IPv6 Routers available
Nov 23 18:49:17 archPC dhcpcd[590]: eno1: offered 172.19.93.208 from 130.132.1.57
Nov 23 18:49:17 archPC dhcpcd[590]: eno1: ignoring offer of 172.19.93.115 from 130.>
Nov 23 18:49:17 archPC dhcpcd[590]: eno1: leased 172.19.93.208 for 120 seconds
Nov 23 18:49:17 archPC dhcpcd[590]: eno1: adding route to 172.19.93.0/24
Nov 23 18:49:17 archPC dhcpcd[590]: eno1: adding default route via 172.19.93.1
Nov 23 18:49:17 archPC dhcpcd[590]: forked to background, child pid 683
[david@archPC ~]$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution
[david@archPC ~]$

jasonwryan · 2018-11-24 05:17:56

So, connect manually and identify the issue: https://wiki.archlinux.org/index.php/Ne … figuration

Scimmia · 2018-11-24 05:18:51

Can you ping an IP, say 8.8.8.8? It may just be a DNS issue.

darkghost568 · 2018-11-24 06:13:00

jasonwryan wrote:

So, connect manually and identify the issue: https://wiki.archlinux.org/index.php/Ne … figuration

I'm sorry, I'm still very new to this. Could you help me out a bit? I'm not sure what to put for "address/prefix_len" under the wiki's

# ip address add address/prefix_len broadcast + dev interface

https://wiki.archlinux.org/index.php/Ne … _addresses , or how to set up the routing table.

Scimmia wrote:

Can you ping an IP, say 8.8.8.8? It may just be a DNS issue.

Here's the output for that:

[david@archPC ~]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.1.4.40 icmp_seq=4 Packet filtered
From 10.1.4.40 icmp_seq=14 Packet filtered
From 10.1.4.40 icmp_seq=25 Packet filtered
From 10.1.4.40 icmp_seq=29 Packet filtered
From 10.1.4.40 icmp_seq=32 Packet filtered
From 10.1.4.40 icmp_seq=37 Packet filtered
From 10.1.4.40 icmp_seq=40 Packet filtered
^C
--- 8.8.8.8 ping statistics ---
43 packets transmitted, 0 received, +7 errors, 100% packet loss, time 599ms

[david@archPC ~]$

seth · 2018-11-24 14:29:44

Well, yeah - there's apparently a firewall/iptables/nftables at play.
Either locally, on your router or whatever.
What's weird is that you get a lease for 172.19.93.208 while the response comes from 10.1.4.40, ie. a different subnet.
How's the network actually laid out? Are there virtual machines at play? VPNs? Other proxies?
Where's the WiFi? (Are you maybe using that?)

Elaborate on the above and post the outputs of

ip a
ip r

darkghost568 · 2018-11-25 01:27:14

seth wrote:

Well, yeah - there's apparently a firewall/iptables/nftables at play.
Either locally, on your router or whatever.
What's weird is that you get a lease for 172.19.93.208 while the response comes from 10.1.4.40, ie. a different subnet.
How's the network actually laid out? Are there virtual machines at play? VPNs? Other proxies?
Where's the WiFi? (Are you maybe using that?)
Elaborate on the above and post the outputs of
ip a
ip r

Not entirely sure how the network is laid out, sorry. I'd assume it's standard University networking, whatever that may be. No virtual machines -- I'm booting Arch over USB via an external hard drive. No VPNs, no proxies. It was working great until the update a few days ago. Ethernet is working fine when I dual boot Windows too (main internal drive, separate from the external Arch HDD -- not a partition). WiFi is nearby but it's a big pain because I need to login using my University netID, so I don't use that; I only use ethernet because it connects without additional login details.

As requested:

[david@archPC ~]$ 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 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 54:a0:50:d5:1c:af brd ff:ff:ff:ff:ff:ff
3: wlp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 40:e2:30:85:b9:81 brd ff:ff:ff:ff:ff:ff
[david@archPC ~]$ ip r
[david@archPC ~]$

Also, my Arch install is mostly vanilla, but if there's a particular package that is known to conflict with networking (idk), if it helps, here's a list of my installed packages to control-F (https://pastebin.com/EdbjrXND)

darkghost568 · 2018-11-25 04:13:43

Ok so I was able to tether my phone's internet connection:

[david@archPC ~]$ ip link         
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 54:a0:50:d5:1c:af brd ff:ff:ff:ff:ff:ff
3: wlp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 40:e2:30:85:b9:81 brd ff:ff:ff:ff:ff:ff
4: enp0s20u2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 36:af:ad:05:aa:c4 brd ff:ff:ff:ff:ff:ff
[david@archPC ~]$ sudo ip link set enp0s20u2 up
[sudo] password for david: 
[david@archPC ~]$ sudo systemctl start dhcpcd@enp0s20u2.service
[david@archPC ~]$ ping www.google.com
PING www.google.com (74.125.195.106) 56(84) bytes of data.
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=1 ttl=33 time=121 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=2 ttl=33 time=127 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=3 ttl=33 time=133 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=4 ttl=33 time=136 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=5 ttl=33 time=124 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=6 ttl=33 time=134 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=7 ttl=33 time=190 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=8 ttl=33 time=134 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=9 ttl=33 time=142 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=10 ttl=33 time=131 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=11 ttl=33 time=131 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=12 ttl=33 time=137 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=13 ttl=33 time=128 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=14 ttl=33 time=126 ms
64 bytes from wj-in-f106.1e100.net (74.125.195.106): icmp_seq=15 ttl=33 time=125 ms
^C
--- www.google.com ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 42ms
rtt min/avg/max/mdev = 120.995/134.574/190.105/15.791 ms
[david@archPC ~]$ sudo systemctl stop dhcpcd@enp0s20u2.service


###Unplugged my phone tether###


[david@archPC ~]$ sudo ip link set eno1 up     
[david@archPC ~]$ sudo systemctl start dhcpcd@eno1.service     
[david@archPC ~]$ ping www.google.com                         
ping: www.google.com: Temporary failure in name resolution
[david@archPC ~]$ sudo systemctl status dhcpcd@eno1.service
● dhcpcd@eno1.service - dhcpcd on eno1
   Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled; vendor preset>
   Active: active (running) since Sat 2018-11-24 22:51:18 EST; 57s ago
  Process: 1080 ExecStart=/usr/bin/dhcpcd -q -w eno1 (code=exited, status=0/SUCCESS)
 Main PID: 1124 (dhcpcd)
    Tasks: 1 (limit: 4915)
   Memory: 4.0M
   CGroup: /system.slice/system-dhcpcd.slice/dhcpcd@eno1.service
           └─1124 /usr/bin/dhcpcd -q -w eno1

Nov 24 22:51:04 archPC dhcpcd[1080]: eno1: soliciting an IPv6 router
Nov 24 22:51:05 archPC dhcpcd[1080]: eno1: soliciting a DHCP lease
Nov 24 22:51:17 archPC dhcpcd[1080]: eno1: no IPv6 Routers available
Nov 24 22:51:18 archPC dhcpcd[1080]: eno1: offered 172.19.93.61 from 130.132.1.56
Nov 24 22:51:18 archPC dhcpcd[1080]: eno1: ignoring offer of 172.19.93.68 from 130.>
Nov 24 22:51:18 archPC dhcpcd[1080]: eno1: leased 172.19.93.61 for 120 seconds
Nov 24 22:51:18 archPC dhcpcd[1080]: eno1: adding route to 172.19.93.0/24
Nov 24 22:51:18 archPC dhcpcd[1080]: eno1: adding default route via 172.19.93.1

[david@archPC ~]$

Still no luck with wired ethernet over eno1 though. Hopefully these results will provide some insight.

circleface · 2018-11-25 04:57:17

When you are in a state where you are getting

ping: www.google.com: Temporary failure in name resolution

try to ping 8.8.8.8 and see if that works.

darkghost568 · 2018-11-25 05:11:18

circleface wrote:

When you are in a state where you are getting
ping: www.google.com: Temporary failure in name resolution
try to ping 8.8.8.8 and see if that works.

https://bbs.archlinux.org/viewtopic.php … 8#p1818358

bugsmanagement · 2018-11-25 06:00:41

darkghost568 wrote:

[david@archPC ~]$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution
[david@archPC ~]$

At that time, was /etc/resolv.conf properly populated? If so, did you try to verify if DNS nameserver were reachable with other tools like drill, host, dig?

EDIT: This could simply be network failure at the university?

Last edited by bugsmanagement (2018-11-25 06:01:42)

darkghost568 · 2018-11-25 06:05:54

bugsmanagement wrote:

darkghost568 wrote:
[david@archPC ~]$ ping www.google.com
ping: www.google.com: Temporary failure in name resolution
[david@archPC ~]$ 
At that time, was /etc/resolv.conf properly populated? If so, did you try to verify if DNS nameserver were reachable with other tools like drill, host, dig?
EDIT: This could simply be network failure at the university?

Yes, resolv.conf seem to be properly populated; it says it's been generated by NetworkManager. Since I was able to get internet when tethered, I reinstalled dhcpcd (still didn't work), then stopped/disabled the service and installed and ran NetworkManager, without any luck (https://imgur.com/a/zJfP45m). I haven't heard of the other tools you mentioned; could you provide some advice on how to use them, please? I'm still very new haha.

It's not a network failure at Uni since when I boot to windows, ethernet works fine.

Last edited by darkghost568 (2018-11-25 06:14:12)

bugsmanagement · 2018-11-25 06:12:52

dig and host, haven't used drill myself, are simple utilities that are quite easy to use for a simple lookups, dig google.com or host google.com.

darkghost568 · 2018-11-25 06:22:30

bugsmanagement wrote:

dig and host, haven't used drill myself, are simple utilities that are quite easy to use for a simple lookups, dig google.com or host google.com.

Oh ok cool, good to know. Here are the outputs:

[david@archPC ~]$ dig www.google.com

; <<>> DiG 9.13.4 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52529
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; Query time: 0 msec
;; SERVER: 130.132.1.9#53(130.132.1.9)
;; WHEN: Sun Nov 25 01:18:23 EST 2018
;; MSG SIZE  rcvd: 43

[david@archPC ~]$ host www.google.com
Host www.google.com not found: 5(REFUSED)
[david@archPC ~]$

bugsmanagement · 2018-11-25 06:29:01

Can you edit that post and include the contents of your /etc/resolv.conf?

Perhaps, if the university is not blocking UDP port 53, you can try replacing what you have now with 1.1.1.1 instead?

darkghost568 · 2018-11-25 06:36:13

bugsmanagement wrote:

Can you edit that post and include the contents of your /etc/resolv.conf?
Perhaps, if the university is not blocking UDP port 53, you can try replacing what you have now with 1.1.1.1 instead?

Hm after looking at the resolv.conf it seemed like it was going through secure addresses, which is why I was hesitant, but I suppose I can include it. When you say "replace with 1.1.1.1" do you mean ping 1.1.1.1 instead of 8.8.8.8?

bugsmanagement · 2018-11-25 06:44:45

I mean, in /etc/resolv.conf

nameserver 1.1.1.1

Instead of what is supplied by dhcpcd. For whatever reason, that currently configured nameserver is refusing to answer queries by the results from dig.

[david@archPC ~]$ dig www.google.com

; <<>> DiG 9.13.4 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52529
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; Query time: 0 msec
;; SERVER: 130.132.1.9#53(130.132.1.9)
;; WHEN: Sun Nov 25 01:18:23 EST 2018
;; MSG SIZE  rcvd: 43

Actually, looking over this once more, that nameserver at 130.132.1.9 is the one refusing the queries. It would be interesting to see what DNS nameserver that are configured for Windows to compare.

darkghost568 · 2018-11-25 06:53:54

bugsmanagement wrote:

I mean, in /etc/resolv.conf
nameserver 1.1.1.1
Instead of what is supplied by dhcpcd. For whatever reason, that currently configured nameserver is refusing to answer queries by the results from dig.
[david@archPC ~]$ dig www.google.com

; <<>> DiG 9.13.4 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52529
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com.                        IN      A

;; Query time: 0 msec
;; SERVER: 130.132.1.9#53(130.132.1.9)
;; WHEN: Sun Nov 25 01:18:23 EST 2018
;; MSG SIZE  rcvd: 43
Actually, looking over this once more, that nameserver at 130.132.1.9 is the one refusing the queries. It would be interesting to see what DNS nameserver that are configured for Windows to compare.

Ah. Here is my resolv.conf:

# Generated by NetworkManager
search its.yale.internal
nameserver 130.132.1.9
nameserver 130.132.1.10
nameserver 205.171.3.26
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 205.171.2.26

And here is what Windows is using:

Microsoft Windows [Version 10.0.17763.134]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>nslookup 130.132.173.78
Server:  serv1.net.yale.edu
Address:  130.132.1.9

Name:    nat-130-132-173-79.central.yale.edu
Address:  130.132.173.78

Last edited by darkghost568 (2018-11-25 07:11:43)

bugsmanagement · 2018-11-25 06:59:25

Yeah, like I said, you can opt for 1.1.1.1 or 8.8.8.8 instead, that is if it's reachable. No idea why it would be refusing queries. Sorry.

nameserver 1.1.1.1

EDIT: This would at least get you back to working state. I would also report this to the IT department, you could refer them to this post.

EDIT 2: Alternatively, you can try the following to very any of those name servers are actually responding.

dig @130.132.1.10 google.com
dig @205.171.3.26 google.com
dig @205.171.2.26 google.com

Last edited by bugsmanagement (2018-11-25 07:06:34)

darkghost568 · 2018-11-25 07:23:48

bugsmanagement wrote:

Yeah, like I said, you can opt for 1.1.1.1 or 8.8.8.8 instead, that is if it's reachable. No idea why it would be refusing queries. Sorry.
nameserver 1.1.1.1
EDIT: This would at least get you back to working state. I would also report this to the IT department, you could refer them to this post.
EDIT 2: Alternatively, you can try the following to very any of those name servers are actually responding.
dig @130.132.1.10 google.com
dig @205.171.3.26 google.com
dig @205.171.2.26 google.com

lol IT department is pretty shit, doubt they'd care. Here's my revised resolve.conf:

# Generated by NetworkManager
search its.yale.internal
 nameserver 1.1.1.1
nameserver 130.132.1.9
nameserver 130.132.1.10
#nameserver 205.171.3.26
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 205.171.2.26

And here's what those commands returned:

[david@archPC ~]$ dig @130.132.1.10 google.com

; <<>> DiG 9.13.4 <<>> @130.132.1.10 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 22564
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      A

;; Query time: 0 msec
;; SERVER: 130.132.1.10#53(130.132.1.10)
;; WHEN: Sat Nov 24 21:16:52 EST 2018
;; MSG SIZE  rcvd: 39

[david@archPC ~]$ dig @250.171.3.26 google.com

; <<>> DiG 9.13.4 <<>> @250.171.3.26 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
[david@archPC ~]$ dig @205.171.2.26 google.com

; <<>> DiG 9.13.4 <<>> @205.171.2.26 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
[david@archPC ~]$

Arch Linux

#1 2018-11-24 03:25:58

Can't connect via ethernet after update

#2 2018-11-24 03:39:20

Re: Can't connect via ethernet after update

#3 2018-11-24 04:10:27

Re: Can't connect via ethernet after update

#4 2018-11-24 04:18:00

Re: Can't connect via ethernet after update

#5 2018-11-24 04:33:54

Re: Can't connect via ethernet after update

#6 2018-11-24 04:38:31

Re: Can't connect via ethernet after update

#7 2018-11-24 04:58:15

Re: Can't connect via ethernet after update

#8 2018-11-24 05:17:56

Re: Can't connect via ethernet after update

#9 2018-11-24 05:18:51

Re: Can't connect via ethernet after update

#10 2018-11-24 06:13:00

Re: Can't connect via ethernet after update

#11 2018-11-24 14:29:44

Re: Can't connect via ethernet after update

#12 2018-11-25 01:27:14

Re: Can't connect via ethernet after update

#13 2018-11-25 04:13:43

Re: Can't connect via ethernet after update

#14 2018-11-25 04:57:17

Re: Can't connect via ethernet after update

#15 2018-11-25 05:11:18

Re: Can't connect via ethernet after update

#16 2018-11-25 06:00:41

Re: Can't connect via ethernet after update

#17 2018-11-25 06:05:54

Re: Can't connect via ethernet after update

#18 2018-11-25 06:12:52

Re: Can't connect via ethernet after update

#19 2018-11-25 06:22:30

Re: Can't connect via ethernet after update

#20 2018-11-25 06:29:01

Re: Can't connect via ethernet after update

#21 2018-11-25 06:36:13

Re: Can't connect via ethernet after update

#22 2018-11-25 06:44:45

Re: Can't connect via ethernet after update

#23 2018-11-25 06:53:54

Re: Can't connect via ethernet after update

#24 2018-11-25 06:59:25

Re: Can't connect via ethernet after update

#25 2018-11-25 07:23:48

Re: Can't connect via ethernet after update

Board footer