Estoy trabajando en una red, como se describe a continuación: un BT HomeHub 5 y un extensor WiFi Netgear EX6150. Hay otros puntos en la red, aunque los omití por brevedad, y todas las líneas discontinuas de color rosa son WiFi.
El problema que estoy viendo es que la PC 1no puedo(no lo hará) comunicarse con la PC 2, pero mi teléfonovoluntad. Por supuesto, mi teléfono tiene la capacidad de saltar y conectarse al extensor directamente, y actualmente no puedo descartar que eso desempeñe un papel aquí.
La misma situación se aplica a la PC 1 que intenta comunicarse con otros hosts en el extensor WiFi.
Todos los anfitriones tienen acceso a Internet.
He descubierto que el extensor "munge" Direcciones MAC, pero no soy capaz de descifrarlaspor qué. Por ejemplo, la dirección MAC de la PC 2 es 88:b1:11:f4:e0:66, pero la interfaz del enrutador (y los hosts conectados al enrutador) verán que se comunica como 02:0f:b5:f4:e0:66. Hay una sección terriblemente escrita en elmanualenpágina 33, y no parece haber una manera de desactivarlo. No veo ninguna razón técnica para esto y actualmente estoy apostando a que esto sea una parte clave del problema.
Es hora de partes técnicas.
- La PC 1 es
192.168.1.74/1c:3e:84:c8:0c:08(según lo informado por el sistema operativo) - PC 2 es
192.168.1.16/88:b1:11:f4:e0:66(según lo informado por el sistema operativo)
Mi teléfono escaneará alegremente la red (usandoFing), descubre el host y hazle ping... como se mencionó anteriormente, la PC 1 no lo hará.
Intenté agregar manualmente la información de la dirección de la PC 2 a la tabla ARP de la PC 1:
C:\WINDOWS\system32>netsh interface ip add neighbors 14 192.168.1.16 02-0f-b5-f4-e0-66
C:\WINDOWS\system32>arp -a
Interface: 192.168.1.74 --- 0xe
Internet Address Physical Address Type
...
192.168.1.16 02-0f-b5-f4-e0-66 static
...
C:\WINDOWS\system32>ping 192.168.1.16
Pinging 192.168.1.16 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.1.16:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\WINDOWS\system32>
Entonces esto claramente no esjustoun problema de ARP.
Mirando esto desde la perspectiva de la PC 2, tomé un tcpdumpping durante un:
$ tcpdump -enr dump.cap
11:37:45.730405 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1317, length 40
11:37:45.730468 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
11:37:45.764667 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
11:37:45.764678 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1317, length 40
No hay who-hasantes de la solicitud de eco ICMP, como lo hemos establecido a mano... pero la PC 2 responde claramente con una respuesta de eco 1c:3e:84:c8:0c:08después de una consulta ARP exitosa (bueno), pero la PC 1 afirma que nunca la recibe.
Además, después del ping, la PC 2 tiene la dirección de la PC 1 en su tabla ARP (la eliminé antes):
$ arp -n
Address HWtype HWaddress Flags Mask Iface
...
192.168.1.74 ether 1c:3e:84:c8:0c:08 C wlp3s0
...
Repetir un ping con Wireshark en la PC 1 y tcpdumpen la PC 2 revela lo siguiente (consulte los volcados a continuación):
- El tráfico desde PC 1 → PC 2 parece estar bien
- No hay manipulación MAC de la fuente
- El tráfico de PC 2 → PC 1 solo se recibe si es una transmisión (por ejemplo: la solicitud ARP)
- AlláesMAC munging de la fuente
ordenador 1
$ tcpdump -enr pc1_dump4.cap
reading from file pc1_dump4.cap, link-type EN10MB (Ethernet)
12:17:59.525610 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:17:59.641049 02:0f:b5:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:17:59.641080 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:04.345340 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:09.346886 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:14.347539 1c:3e:84:c8:0c:08 > 02:0f:b5:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40
ordenador 2
$ tcpdump -enr pc2_dump4.cap
reading from file dump4.cap, link-type EN10MB (Ethernet)
12:18:02.206931 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1330, length 40
12:18:02.206995 88:b1:11:f4:e0:66 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.74 tell 192.168.1.16, length 28
12:18:02.289242 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.74 is-at 1c:3e:84:c8:0c:08, length 28
12:18:02.289254 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1330, length 40
12:18:07.122444 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1331, length 40
12:18:07.122484 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1331, length 40
12:18:12.037691 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1332, length 40
12:18:12.037729 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1332, length 40
12:18:17.170982 1c:3e:84:c8:0c:08 > 88:b1:11:f4:e0:66, ethertype IPv4 (0x0800), length 74: 192.168.1.74 > 192.168.1.16: ICMP echo request, id 1, seq 1333, length 40
12:18:17.171025 88:b1:11:f4:e0:66 > 1c:3e:84:c8:0c:08, ethertype IPv4 (0x0800), length 74: 192.168.1.16 > 192.168.1.74: ICMP echo reply, id 1, seq 1333, length 40
Si invierto la dirección (la PC 2 envía solicitudes de eco a la PC 1), la PC 1 nunca ve la solicitud.
Deshabilitar el firewall de Windows no ayuda.
Como último recurso, conectar la PC 1 al enrutador mediante Ethernet resuelve el problema... sin embargo, actualmente no es una solución aceptable.
¿Alguien puede ayudar?