Cómo saber si la NIC del Mac está muerta o moribunda

Tenemos una red doméstica que antes era perfecta. Nos mudamos hace unos seis meses, y nuestra nueva casa es una casa victoriana mucho más grande, con gruesos muros de piedra, y uno de nuestros Macs está teniendo problemas importantes.

El router/módem está en una esquina de la casa, en la planta baja (y, por desgracia, no se puede mover, ya que hay un host ESXi, un conmutador y un sistema de CCTV que dependen de él) -o el primer piso, si eres americano- y el Mac está en el estudio del primer piso (segundo piso, etc.).

Nos hicimos con un par de extensores Netgear, y en lugar de conectar cada uno de ellos al módem/router "central", conectamos el más cercano a éste, y luego cada uno más alejado, lo conectamos al extensor siguiente.

A veces, tenemos

mac.invalid.com   ~  %{ping -c 15 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=11.208 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=22.945 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=15.135 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=17.999 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=11.019 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=117 time=14.088 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=24.509 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=14.423 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=76.470 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=117 time=30.820 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=117 time=60.230 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=16.564 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=117 time=23.046 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=117 time=22.266 ms

--- 8.8.8.8 ping statistics ---
15 packets transmitted, 14 packets received, 6.7% packet loss
round-trip min/avg/max/stddev = 11.019/25.766/76.470/18.450 ms

Y a veces, es..

mac.invalid.com    ~  %{ping -c 15 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=1640.033 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=1497.046 ms
Request timeout for icmp_seq 3
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=2226.044 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=1224.378 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=2220.866 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=117 time=2619.425 ms
Request timeout for icmp_seq 8
64 bytes from 8.8.8.8: icmp_seq=7 ttl=117 time=2343.340 ms
Request timeout for icmp_seq 10
64 bytes from 8.8.8.8: icmp_seq=8 ttl=117 time=3246.439 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=117 time=3491.467 ms
Request timeout for icmp_seq 13
64 bytes from 8.8.8.8: icmp_seq=12 ttl=117 time=2709.148 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=117 time=3112.649 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=117 time=3733.902 ms

--- 8.8.8.8 ping statistics ---
15 packets transmitted, 12 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 1224.378/2505.395/3733.902/766.261 ms

Y a veces, ni siquiera puede conseguir un solo pingback.

No debería haber problemas de conexión con el extensor Netgear en cuestión, ya que está a unos dos metros de donde estoy sentado, y al otro lado de una pared de pladur.

Tal vez valga la pena mencionar que todos los demás dispositivos que se encuentran en esta sala no tienen problemas para conectarse a Internet a través del mismo extensor.

¿El Mac está listo para ir al taller o a la basura? Es un Mac Mini de finales de 2012.

EDIT: He probado a hacer ping a mi puerta de enlace. Los siguientes tiempos de espera se produjeron exactamente al mismo tiempo que los tiempos de espera para el ping a la caja DNS de Google.

mac.invalid.com   ~  %{ping 192.168.1.1 
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=19.014 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=19.127 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=3.680 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=19.635 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=21.600 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=3.036 ms
Request timeout for icmp_seq 7
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=27.741 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=28.008 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=9.257 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=24.714 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=13.685 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=6.382 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=40.792 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=9.818 ms
Request timeout for icmp_seq 16
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=19.506 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=9.401 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=9.042 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=12.356 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=12.392 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=14.834 ms
^C
--- 192.168.1.1 ping statistics ---
23 packets transmitted, 20 packets received, 13.0% packet loss
round-trip min/avg/max/stddev = 3.036/16.201/40.792/9.134 ms

EDIT 2: He borrado la tabla de enrutamiento, por si acaso la había estropeado al trastear con ella hace un año.