Los Macs no pueden verse entre sí a través de un cable Ethernet. MacOS no puede configurar el enrutamiento 169.254. ¿Por qué? ¿Por qué? ¿Cómo lo arreglo? ¿Viola el RFC 3927? Sugerencia: ¿multihomed?

Question

Los Macs no pueden verse entre sí a través de un cable Ethernet. MacOS no puede configurar el enrutamiento 169.254. ¿Por qué? ¿Por qué? ¿Cómo lo arreglo? ¿Viola el RFC 3927? Sugerencia: ¿multihomed?

Preguntado el 3 de Septiembre, 2020: Cuando se hizo la pregunta
109 visitas: Cuantas visitas ha tenido la pregunta
4 Respuestas: Cuantas respuestas ha tenido la pregunta
Abierta: Estado actual de la pregunta

(Un título demasiado complicado: Los Macs conectados con un cable Ethernet no se pueden ver entre sí - MacOS falla al configurar el enrutamiento 169.254, AKA configuración de la dirección de enlace local. ¿Por qué? ¿Cómo lo soluciono? ¿Viola el RFC 3927? Sugerencia: Uno de los Macs tiene una conexión Ethernet (a través de Wi-Fi) normal y en funcionamiento, lo que puede convertirlo en un host multi-homed).

Estoy intentando comunicarme entre dos Macs a través de un cable Ethernet. Esto debería "funcionar", pensé, pero no parece que MacOS esté configurando automáticamente las cosas como se supone que debe hacerlo. No consigue configurar el enrutamiento 169.254, es decir, el direccionamiento de enlace local para que los Macs puedan comunicarse correctamente. En otras palabras, no logra configurar completamente las interfaces en0 (TP Ethernet) para que el direccionamiento de enlace local funcione automáticamente. Pensé que como aparentemente seguía RFC 3927 sobre Configuración Dinámica de Direcciones Link-Local IPv4, "simplemente funcionaría", pero no es así.

En particular es asignar automáticamente IPs a los dispositivos, pero es NO enrutamiento de paquetes/configuración de la tabla de enrutamiento en consecuencia.

Del RFC:

Resumen

... Este documento describe cómo un host puede configurar automáticamente una interfaz con una dirección IPv4 dentro del prefijo 169.254/16 que es válida para la comunicación con otros dispositivos conectados al mismo enlace físico (o lógico).

¿Viola MacOS el RFC 3927? ¿Por qué dos Macs conectados a través de un cable Ethernet, cada uno con una asignación automática de 169.254/16 direcciones link-local ¿se ven?

Esto podría ser un arreglo; aún no lo he descubierto: sudo route -n add -net 192.168/16 169.254.14.233 . (Es la IP autoasignada automáticamente).

Añade un par de líneas a la tabla de enrutamiento (salida de netstat -rn| grep -v :: ) :

169.254.14.233     ac:87:a3:20:db:5e  UHLSW           2        0     lo0        
192.168.0/16       169.254.14.233     UGSc            0        0     en0

Preguntado el 3 de Septiembre, 2020 por Matthew Elvey

2 votos

Mencionas el WiFi y el ethernet. ¿Qué tal si desactivas el WiFi para que sólo te ocupes de la conexión (más rápida) por cable? Cuando hago esto (normalmente migrando a otro Mac) siempre desactivar el WiFi para forzar al Mac a que no intente usar ambos o sólo el WiFi, algo que ya he visto antes.

Comentado el 4 de Septiembre, 2020 por Steve Chambers

0 votos

Es una solución viable. Pero realmente quería mantener uno de los ordenadores conectados a Internet. De hecho, estaba explorando las opciones de migración en el momento en que hice la pregunta.

Comentado el 7 de Octubre, 2020 por Matthew Elvey

0 votos

Por favor, no escribas "resuelto" en la pregunta, acepta la respuesta que te ha ayudado en su lugar. Y la información tanto en la pregunta como en las respuestas podría ser útil en el futuro, así que tampoco hay razón para borrarla.

Comentado el 9 de Octubre, 2020 por Matthew A. Flinchbaugh

Answer 1

4 Respuestas

Answer 2

1voto

Matthew Elvey Puntos 300

Así que estoy viendo la misma conexión un mes después, pero con ambos Macs en modo de arranque normal.

Así que ahora, el enrutamiento 169.254 es configurado con sólo enchufar el cable.

La otra máquina es visible en las tablas de enrutamiento IP y ARP.

El problema ha desaparecido.

(Ahora puedo llegar a la otra máquina con mDNS según @John Keates; ping [the other machine-name, now that I know it].local obras. Pero no puedo retroceder en el tiempo para ver si hubiera funcionado).

Además, me he dado cuenta de que he metido la pata con ese comando de ruta (recién corregido), así que eso podría estar causando algunas cosas raras restantes que no entiendo. (¡Necesito reiniciar este sistema!):

Ah, y acabo de descubrir que mis niveles de Ca en la sangre han estado fuera, así que algunos La confusión que probablemente causó puede haber sido una de las principales causas del (supuesto) problema de MacOS ¡! ~~Cringe.~~ Con el trabajo, veo que vale la pena mantener esta pregunta visible de todos modos.

Hoy, ya veo:

$ ifconfig | grep broad
inet 169.254.14.233 netmask 0xffff0000 broadcast 169.254.255.255
inet 192.168.141.99 netmask 0xffffff00 broadcast 192.168.141.255

y

$ ifconfig | grep broad
inet 169.254.174.186 netmask 0xffff0000 broadcast 169.254.255.255

lo cual es lo esperado.

Pero esto no lo es:

$ ping 169.254.255.255
PING 169.254.255.255 (169.254.255.255): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
ping: sendto: No route to host
Request timeout for icmp_seq 4
ping: sendto: Host is down
Request timeout for icmp_seq 5
  C-c C-c
--- 169.254.255.255 ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss

Entiendo que debería ver respuestas de ping en ambas máquinas para las que esa es su dirección de difusión.

Al hacer ping a la otra IP de difusión, 192.168.141.255, obtengo respuestas de ping de todas las interfaces en vivo con esa dirección IP de difusión, como se esperaba.

Respondido el 7 de Octubre, 2020 por Matthew Elvey (300 Puntos )

Answer 3

0voto

Matthew Elvey Puntos 300

Puede que haya descubierto la respuesta mientras desarrollaba la pregunta.

Probablemente no funciona porque uno de los Macs tiene una dirección enrutable/es multihomed , en cuyo caso la aplicabilidad y la configuración automática se dejan sin definir en la RFC.

El RFC implica una respuesta a la pregunta ( énfasis añadido a los bits más relevantes) en § 2.6.2 etc..:

Resumen

...Las direcciones IPv4 Link-Local sólo se utilizan cuando las direcciones estables y enrutables no son estables (como en redes ad hoc o aisladas).

2.6.2. Reglas de reenvío

... si la dirección de destino está en el prefijo 169.254/16 prefijo ( excluyendo la dirección 169.254.255.255, que es la dirección de difusión para el prefijo Link-Local), entonces el remitente DEBE ARP para la dirección de destino y luego enviar su paquete directamente al destino en el mismo enlace físico. Esto DEBE hacerse hacer si la interfaz está configurada con una dirección Link-Local o una dirección IPv4 enrutable.

En muchas pilas de red, la consecución de esta funcionalidad puede ser tan simple como añadir una entrada en la tabla de enrutamiento indicando que 169.254/16 es directamente alcanzable en el enlace local. Este enfoque no funcionará para los routers o hosts multi-homing . Consulte sección 3 para más discusión sobre los hosts multi-homed .

Sección 3 y luego entra en grandes detalles en cuanto a la razón.

(Por otro lado, Apéndice A dice:

... Los sistemas Mac OS no envían paquetes dirigidos a una dirección Link-Local a la puerta de enlace por defecto si hay una; estas direcciones siempre se resueltas en el segmento local. ...

Me parece que esto no es actualmente cierto).

Y después de leer en Sección 3.3 "Dado que la dirección de HOST2 es no en 169.254/16" Estoy confundido de nuevo, ya que en el escenario proporcionado, creo que será/debería ser el caso que la dirección de HOST2 es en 169.254/16... quizás sea un error en el RFC. Probablemente estoy confundido...

Respondido el 3 de Septiembre, 2020 por Matthew Elvey (300 Puntos )

0 votos

Funciona si usas el nombre de host mDNS, scutil debería mostrarte que eso sigue enrutando correctamente usando una cadena de políticas.

Comentado el 4 de Septiembre, 2020 por John Keates

0 votos

Gracias. (Uno de ellos ya estaba en modo de reinstalación/configuración del sistema operativo, por lo que no pensé en intentarlo, ya que habría tenido que encontrar una forma de averiguar su nombre de host, lo que habría requerido abortar la operación. Todo lo cual no mencioné por el espíritu de SE).

Comentado el 7 de Octubre, 2020 por Matthew Elvey

Answer 4

0voto

Yoan Puntos 1

Citando esto Artículo de Wikipedia :

Blockquote Una Ethernet cable cruzado es un cable cruzado para Ethernet que se utiliza para conectar directamente los dispositivos informáticos. La mayoría de las veces se utiliza para conectar dos dispositivos del mismo tipo, por ejemplo, dos ordenadores (a través de sus controladores de interfaz de red) o dos conmutadores entre sí. En cambio, los cables de conexión o recto Los cables pasantes se utilizan para conectar dispositivos de distintos tipos, como un ordenador a un conmutador de red o un concentrador Ethernet.

Necesitas un cable cruzado para eso

Respondido el 4 de Octubre, 2020 por Yoan (1 Puntos )

Answer 5

0voto

Oskar Puntos 1242

Nunca he tenido que hacer nada, excepto conectar cualquier cable ethernet o FireWire y usar Bonjour (ssh user@mac-one.local) para usar el sufijo MDNS .local para conectarse a los nombres de las máquinas. Todo funciona desde el primer momento.

Tal vez estés buscando un poco de profundidad y no sólo hacer lo que quieres sin preocuparte de un hub o switch o la conexión directa no está lista.

Respondido el 7 de Octubre, 2020 por Oskar (1242 Puntos )

Los Macs no pueden verse entre sí a través de un cable Ethernet. MacOS no puede configurar el enrutamiento 169.254. ¿Por qué? ¿Por qué? ¿Cómo lo arreglo? ¿Viola el RFC 3927? Sugerencia: ¿multihomed?

Respuestas

Preguntas Destacadas

Etiquetas mas usadas

AppleAyuda.com

Powered by:

Los Macs no pueden verse entre sí a través de un cable Ethernet. MacOS no puede configurar el enrutamiento 169.254. ¿Por qué? ¿Por qué? ¿Cómo lo arreglo? ¿Viola el RFC 3927? Sugerencia: ¿multihomed?

Respuestas

Preguntas relacionadas

Preguntas Destacadas

Etiquetas mas usadas

En nuestra red

AppleAyuda.com

Powered by: