mensaje ARP a enc28j60

2

He hecho el controlador para enc28j60 para LPC1788 y estoy tratando de enviar un mensaje UDP a LPC a través de un dispositivo habilitado para wifi (iOS, windows a través de wifi). Pero la transmisión falla. El dispositivo wifi envía la solicitud ARP. LPC envía la respuesta, pero no llega. He comprobado el caché ARP en Windows Machine y se quedó vacío. Cuando hago lo mismo con la máquina conectada por cable, llega correctamente, se llena la caché ARP. Eso concluye que la respuesta ARP se envía y se construye correctamente.

También intenté hacer ping y lo mismo, todos los dispositivos que vienen a través del enrutador no obtuvieron respuesta ARP, pero los dispositivos que están conectados por cable reciben la respuesta ARP.

Pero, la misma placa enc28 está funcionando bien con Arduino. La implementación de Arduino del controlador y Ethernet no fue realizada por mí.

Eso significa que de alguna manera está relacionado con el controlador. Me he olvidado de cambiar alguna opción del chip enc28 o ...

He visto el controlador Arduino pero no pude encontrar ningún error obvio en mi implementación.

¿Alguna idea de lo que podría estar mal?

ACTUALIZACIÓN:

Ahora tengo un enrutador Wifi con tcpdump instalado. Lo ejecuté y olfateé los paquetes de Wifi a Arduino (todo está bien allí. La solicitud ARP, la respuesta ARP y el eco / respuesta Ping se pueden ver en el rastreo). Cuando inicio Wifi a LPC solo veo solicitudes de ARP. Aunque dice que el filtro recibe pocos paquetes, pero no puedo ver esos paquetes en el archivo de volcado. ¿Hay alguna opción en tcpdump para ver datos en bruto?

Lo que puedo ver cuando uso tcpdump con la opción "-i any", es mi respuesta arp perdida. Pero me parece bien.

ARDUINO

ARP Request
0004 0001 0006 d89e 3f87 3ad5 0000 0806
0001 0800 0604 0001 d89e 3f87 3ad5 c0a8
0564 7069 692d 3031 c0a8 0508

ARP Response
0003 0001 0006 7069 692d 3031 0000 0806
0001 0800 0604 0002 7069 692d 3031 c0a8
0508 d89e 3f87 3ad5 c0a8 0564 0000 0000
0000 0000 0000 0000 0000 0000 0000

LPC

ARP Request
0001 0001 0006 d89e 3f87 3ad5 0000 0806
0001 0800 0604 0001 d89e 3f87 3ad5 c0a8
0564 0000 0000 0000 c0a8 0507

ARP Response
0003 0001 0006 891d dc9f da6e 0000 0806
0001 0800 0604 0002 891d dc9f da6e c0a8
0507 d89e 3f87 3ad5 c0a8 0564 0000 0000
0000 0000 0000 0000 0000 0000 0000

No veo ninguna diferencia en la respuesta de LPC (que no funciona) y de Arduino (que funciona).

¿Podría ser algún tipo de problema de tiempo?

LPC

11:39:05.194814 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.194889 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.195001 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.194814 arp who-has 192.168.5.7 tell 192.168.5.113
11:39:05.195537 arp reply 192.168.5.7 is-at 89:1d:dc:9f:da:6e (oui Unknown)
11:39:06.194815 arp who-has 192.168.5.7 tell 192.168.5.113
...

Arduino

11:42:27.712993 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.713068 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.713180 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.712993 arp who-has 192.168.5.8 tell 192.168.5.113
11:42:27.714049 arp reply 192.168.5.8 is-at 70:69:69:2d:30:31 (oui Unknown)
11:42:27.714141 arp reply 192.168.5.8 is-at 70:69:69:2d:30:31 (oui Unknown)  
11:42:27.767303 IP 192.168.5.113 > 192.168.5.8: ICMP echo request, id 56841, seq 0, length 64 
... 
    
pregunta Gossamer

2 respuestas

2

En general, para tener algún tipo de información significativa sobre lo que sucede, necesitará una forma de examinar los paquetes en las redes. Tanto entre los dispositivos Ethernet como el punto de acceso Wifi, y entre el punto de acceso WiFi y las PC conectadas a la red Wifi. En la (s) PC (s), puede ejecutar un analizador de tráfico de red para ver el tráfico que ve esa PC, pero es probable que sus dispositivos Ethernet no tengan recursos suficientes para proporcionar un volcado de tráfico significativo. En ese caso, necesitará algún tipo de rastreador de Ethernet entre los dispositivos Ethernet y el punto de acceso WiFi. La solución más sencilla suele ser un dispositivo Ethernet capaz de captar el tráfico (un concentrador Ethernet simple o un conmutador Ethernet manejable configurado adecuadamente), y una PC lo conectó para recibir el tráfico girado y analizarlo con un analizador de tráfico de red (un software como Wireshark, por ejemplo).

Luego, debe examinar las diferencias entre las solicitudes ARP provenientes de una PC directamente a través de la LAN Ethernet y las que vienen de una PC a través de Wifi, puenteadas a la LAN Ethernet. Estas solicitudes diferirán (por ejemplo: el punto de acceso Wifi pondrá su propia dirección MAC en el encabezado de Ethernet). Además, puede examinar las respuestas "buenas" de su Arduino y las respuestas "malas" de su casilla para ver las diferencias.

    
respondido por el Laszlo Valko
1

Es un poco difícil depurar esto de forma remota. Es absolutamente necesario mirar los marcos en wirehark. Utilice 'tcpdump -s 9999 -w dump.cap' para grabar un archivo pcap.

Errores clásicos de los controladores MAC de cosecha propia:

  • Olvidar rellenar fotogramas a 60 bytes. Resultado: el MAC receptor puede quitar la trama debido a su tamaño inferior.
  • En el controlador de IRQ, leer solo un fotograma de la cola de MAC, en lugar de leer toda la cola. Resultado: los cuadros pueden demorarse (por varios segundos) hasta que llegue otro cuadro.
  • Al copiar datos en / desde la palabra MAC palabra por palabra, preste atención al manejo de un número impar de bytes. De lo contrario, el último byte puede quedar destrozado.
  • confusión endiana. Por lo general, todo es big endian (orden de la red). Es más fácil evitar errores si ensambla su fotograma byte a byte, en lugar de convertir desde enteros o estructuras.

PS: ¿ha elegido usted mismo la dirección MAC? ¿Estás seguro de que no es un multicast? Intente 00: 00: 00: AA: BB: CC en su lugar.

    
respondido por el maxy

Lea otras preguntas en las etiquetas