PIC18F4550 y ENC28J60 conexion correcta, problema con implementacion UDP

[Byron]

Buenas amigos del foro

Llevo un tiempo haciendo programas sencillos para microcontroladores PIC en CCS Compiler, ahora intento implementar un stack UDP/IP para en ENC28j60, creo que voy bien, pero tengo un problema, cualquier software que utilice para gestar la comunicación UDP envía datos al micro, pero no los recibe, lo extraño es que utilizo el software para captura de paquetes Wireshark, y muestra respuesta del micro, sin problema aparente, alguien conoce algo al respecto y puede ayudarme?
A continuación adjunto una serie de capturas de pantalla en las cuales muestro que el analizador de paquetes Wireshark evidencia el paquete enviado desde el micro al computador, lo que quiere decir que el paquete llega a la tarjeta de red del computador pero no pasa a los terminales, he probado el Hercules, y el Indusoft Web Studio V7.1, ambos funcionan perfectamente si se conectan dos PC diferentes; envian paquetes al micro pero no muestran nada desde el mismo.
https://www.dropbox.com/sh/2j6wat8pwstxjqr/AABil8bCmQsnVcLapMd-Q2Tra?dl=0

[KILLERJC]

Dejame ver si entendi..

PC -> micro
Funciona correctamente

micro-> PC
No funciona. Pero no es que no funciona por que no llega, sino que llega pero no deja pasarlo desde la placa de red hacia el programa. Podes ver los campos sino me equivoco con el wireshark

Probaste usar 2 PCs, siendo una de las PC simule el micro enviando una respuesta UDP (cualquiera , supongamos un echo de la primer PC ) y ver exactamente la diferencia entre los paquetes generados por el micro y el de la PC?, Suponiendo que funcione la comunicacion PC-PC utilizando los mismos puertos, etc.

[Byron]

Correcto KILLERJC, del PC al micro funciono correctamente, mientras del micro al PC hay una respuesta pero no puede verse en ningún terminal, solo en Wireshark... si, efectivamente probe conexión udp entre dos PCS y funciona... ademas el micro si responde al ping (ICMP:Echo) Correctamente

Esto muestra en el CMD de windows:

C:\Windows\system32>ping 192.168.1.47

Haciendo ping a 192.168.1.47 con 32 bytes de datos:
Respuesta desde 192.168.1.47: bytes=32 tiempo=11ms TTL=255
Respuesta desde 192.168.1.47: bytes=32 tiempo=4ms TTL=255
Respuesta desde 192.168.1.47: bytes=32 tiempo=4ms TTL=255
Respuesta desde 192.168.1.47: bytes=32 tiempo=4ms TTL=255

Estadísticas de ping para 192.168.1.47:
    Paquetes: enviados = 4, recibidos = 4, perdidos = 0
    (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 4ms, Máximo = 11ms, Media = 5ms

C:\Windows\system32>

Esto muestra en el terminal Hercules: (Muestra primero el reply y luego el request por cuestiones de velocidad(fue programado asi para que conteste rápidamente))

ARP Reply a 192.168.1.30
ARP Request de: 192.168.1.30
Echo Reply a 192.168.1.30Echo request de 192.168.1.30
Echo Reply a 192.168.1.30Echo request de 192.168.1.30
Echo Reply a 192.168.1.30Echo request de 192.168.1.30
Echo Reply a 192.168.1.30Echo request de 192.168.1.30

[KILLERJC]

Sisisi el ping esta correcto ( si esta implementando obvio ) por que la coneccion esta.. se realiza. lo que me llama la atencion es que a pesar que lo recibe NO lo pasa, ¿lo descartara, el firewall lo bloqueara?. Tal ves un error en el paquete. por eso te decia que pruebes con otra PC enviando el mismo paquete y compruebes campo a campo si existe alguna diferencia.

Es lo unico que se me ocurre, ya que un UDP de la PC o un UDP del micro no deberia haber ninguna diferencia ya que tenes Puerto de origen, destino, largo, checksum , y los datos.

Si envias eso es todo igual. Lo que queda es la cabecera de IPv4, que tambien tenga un error no en las direcciones, las cuales son correctas por que llega, sino tal ves en el largo del paquete IPv4.
Son las unicas que se me ocurren.

[Byron]

no es firewall, ya que tanto el Indusoft como el Hercules muestran notificación de firewall donde damos habilitar la conexión, la comunicación es perfecta cuando utilizo los programas en dos computadoras diferentes y envío cualquier dato, el encabezado ip no es ya que icmp(ping) esta montado sobre el mismo segmento de código, incluso comparo los campos y todos coinciden con lo que se desea, realmente no se que hacer, que campo puedo cambiar a modo de prueba??

[KILLERJC]

Es que eso me esta extrañando. Si tu paquete esta realmente siendo recibido y Tiene los valores correctos de cabeceras deberia funcionar correctamente.

La capas fisicas/enlace (PHY/MAC) estan funcionando por que se reciben las datos ( el encapsulado del frame no es un tema del PIC tampoco ) ademas de eso se encarga en ENC. Quedaba solo verificar las cabeceras IP/UDP (largo,checksum,tipo,etc). Que decis que estan funcionando correctamente. Probaste PC-PC y funciona, pero micro-PC no, por eso mismo te pedi que compararas. Que enviaras lo mismo tanto del micro como desde la PC y compararas si habia un campo en la cabecera IP u UDP que estuviera mal o sean diferentes y verificar el por que. Pero decis que eso esta bien.

Si todo eso esta bien, solo queda echarle la culpa al programa de la PC. Ahora por que no aceptaria uno u otro, mas que seleccionar el puerto de escucha no se que otra cosa podria fallar. Pero nuevamente, si funciona PC-PC, no deberia fallar micro-PC. Por que ya estarias por encima de las capa UDP. Yo lo unico que presiento es justamente algun error de las cabeceras y que es eso lo que puede estar fallando. Y que se termine descartando el paquete por que llego en mal estado por ejemplo. Otra cosa no puedo pensar... no hay demasiada logica tras mi razonamiento.

Y nuevamente lo unico que puedo recomendarte que pruebes y verifiques exactamente lo de comparar esos 2 paquetes (PIC y PC). Conecta uno y luego otro usando el mismo puerto,IP,  o ambos con distinto IP y puerto y que envien UDP cada 1s asi no saturas la linea con paquetes y podes compararlos con el wireshark. Otra cosa realmente no se me ocurre.

[Byron]

Bueno muchas gracias

Creo que empezare de cero con el segmento de código en la implementacion UDP de forma muy minuciosa aver que puede resultar, pronto estaré realimentando lo que suceda...

[KILLERJC]

Yo probe algo parecido con un pedido de DNS:



Ahi ves claramente las secciones y es lo que pedia que compares, o si lo queres en hexa lo tenes debajo

https://es.wikipedia.org/wiki/Cabecera_IP
https://en.wikipedia.org/wiki/User_Datagram_Protocol

Finalmete una cosa que no sabia, el cheksum del UDP es opcional, si lo pones a 0 se indica como no usado. Lo feo es que perdes la fiabilidad de los datos.

PD: No te guies por el calculo de cheksum en los envios de la PC, por que puede que el cheksum se agrege por hardware entonces no esta precalculado  y da erroneo el wireshark, si en la recepcion podrias habilitar el cheksum del wireshark y observar que todo este correcto (viene desactivado por defecto).


Y yo te decia que lo compares para que veas que esta mal y sepas a que parte del codigo UDP dirigirte, creo que es lo mas simple para llegar a cual es el problema. Y no tener que repasar todo el codigo del UDP

[Byron]

Muy bien, sucede que como dice nuestro amigo KILLERJC, el checksum es opcional, si el valor se pone a 0000 el receptor no lo comprueba, si por el contrario, se agrega un valor diferente, debe hacerse la comprobación; sucede que en dicho calculo debe agregarse las direcciones IP origen, e IP destino...  por ese motivo no funcionaba, tenia un checksum solo encabezadp IP+datos, el receptor los comprobaba, pero nunca ivan a coincidir, lo implemente de dos formas: 1.poniendo checksum=0000 y funciona; 2.checksum con direcciones IP y tambien funciona.

Muchas gracias amigo KILLERJC, aportaste mucho en mi solucion.

[KILLERJC]

De nada Byron, habia que separar el problema en partes y seguir la logica, y por suerte era la solucion.

Yo estoy mas impresionado por vos, que te hiciste el stack IP por vos mismo, eso si que es un logro. Asi que todo mi respeto hacia vos. Y un gusto participar en un problema de estos.