Ethernet - UDP, RJ45 con Kinetis

[planeta9999]

 

Si, al final era el cortafuegos, lo he desactivado y los paquetes UDP han entrado como un tiro. Que maravilla, me temía lo peor, un error de diseño de mi placa, y el cliente está que echa chispas porque le envíe mañana mismo la placa.

Por cierto el broadcast con la 255.255.255.255 funciona de fábula, luego probaré con la 192.168.1.255 a ver si también funciona, y finalmente con la IP local de mi PC, la 192.168.1.3.

También he tenido y sigo teniendo problemas con el bootloader de uTastker, con este me pasa una cosa muy rara, no me carga firmware sin son archivos pequeños, probado con ficheros de 10K hasta 24K, sin embargo me los carga sin problemas para tamaños mayores, probado con uno de 67K. Creo que es algún parámetro de la encriptación, ya le he preguntado al autor en los foros de NXP a ver si me echa un cable.

De momento mañana mismo le envío al cliente la placa con el bootloader cargado, y por email ya le enviaré el firmware. Si no consigo que cargue ficheros pequeños, tendré que engordar artificialmente el tamaño del firmware. ¿ Se os ocurre como hacerlo ?, en principio puse una matriz gorda para que se almacene en Flash, pero se ve que la optimización de GCC no se deja engañar y me deja el objeto igual de tamaño.

[planeta9999]

Lo que no se ahora mismo es como configurar el puñetero cortafuegos, para que me deje pasar el tráfico sin necesidad de desactivarlo, por cuestiones de seguridad.

[planeta9999]

Ya está, arreglado, configuré, en el cortafuegos, una regla para permitir el tráfico entrante desde 192.168.1.189, y ya va perfecto sin desactivar el cortafuegos.

Lo que no veo es que se me encienda ninguno de los dos led de actividad del RJ45, uno ya detecté según el datasheet, que lo he conectado al revés, y el otro no se porque no da señales de vida. Es un mal menor, que no impide que funcione, pero queda bonito que parpadeen los leds de actividad, seguramente el otro también estará al revés.

[planeta9999]

 

He seguido con las pruebas y hay algo que no se como interpretarlo.

Modifico el fuente para que envíe por UDP una matriz char con 4096 carácteres, ejecuto WireShark y me recibe el envío en dos trozos, uno de 1514 bytes y el otro de 618 bytes.

No me salen las cuentas, aunque los paquetes UDP salgan troceados, me faltan bytes, no se si hay alguna limitación en el tamaño de los paquetes a enviar, envío 4096 bytes y recibo solo 2132 bytes en dos trozos (1514+618).

Buscando por Google, me encuentro con esta parrafada sobre UDP y el tamaño de los paquetes, entiendo que hay que enviar paquetes de un máximo de 1472 bytes de datos, pero no entiendo porque estoy recibiendo dos trozos de datos, cuya suma supera los 1472 bytes pero no llega a los 4096 bytes enviados:

" El campo de longitud se refiere a la longitud total, en bytes, de la cabecera y los datos. La aplicación que utiliza UDP, debe controlar el tamaño del paquete UDP (la cantidad de bytes enviados en un mismo paquete UDP) si quiere evitar que el nivel IP fragmente el paquete UDP porque se ha excedido el MTU (Maximum Transmission Unit) del medio físico. Por ejemplo, si el medio físico es una Ethernet con tramas Ethernet II, el campo de datos de la trama Ethernet tiene una longitud máxima de 1500 bytes. En este caso, la longitud máxima del datagrama IP encapsulado en una trama Ethernet sera de 1500 bytes. Si utilizamos UDP como protocolo de transporte, la cantidad de bytes de usuario (campo data del datagrama UDP) será como máximo 1500−20−8=1472  bytes (a 1500 se le resta la cabecera IP, usualmente 20 bytes, y la cabecera UDP, 8 bytes) "

[KILLERJC]

envío 4096 bytes y recibo solo 2132 bytes en dos trozos (1514+618).

En realidad lo que te dice ese parrafo extra largo, es que tu dato esta "encapsulado",
Es decir que a tu dato se le agrega (una cabecera) la informacion de IP https://es.wikipedia.org/wiki/Cabecera_IP,
Luego a tu dato + cabecera IP, se lo vuelve a encapsular nuevamente y se le agrega lo referente a UDP https://es.wikipedia.org/wiki/User_Datagram_Protocol.

Por lo tanto los datos a enviar maximo en 1 solo paquete es de 1472 bytes. Que si observas en la imagen del wireshark, dice Len = 1472. Tambien podes ver la imagen donde te desglosa cada uno de los paquetes, y dice Data ( 1472 bytes )

De alli es como lo maneje el stack UDP/IP en tu micro, si decide enviar 3 completos y luego 1 lo que sobra, lo va a hacer. Pero parece que decide ir por numeros que son multiplos de 2,
Si sumas ambos lenght tenes que 1472 + 576 = 2048

El tema esta en los otros 2048 bytes que faltan, o tal ves en el wireshark no lo mostraste, o tal ves nunca se envio.

[tsk]

Abre cualquiera de los paquetes con doble click.

Ahí verás que el tamaño del del dato recibido va a ser de 4096bytes. El mismo protocolo lo reensambla, y probablemente wireshark sólo reporta el último de los paquetes recibidos.

Esto es debido que existe un tamaño máximo de paquete que se conoce como Unidad Máxima de Transmisión o MTU, por lo general este valor está en 1500bytes pero de esos 1500 bytes 20 son para el encabezado. Por lo tanto te quedan 1480 bytes de carga últil o datos.

Si abres uno de los paquetes debes de observar varios campos:

Frame
Ethernet
Internet Protocol Version 4
User Datagram Protocol
Data

Data debe de ser del tamaño de los 4096 bytes y dentro de Internet Protocol
Hay una sección que te indica cuantos paquetes fueron enviados y el tamaño de la carga útil.



Aunque yo me quedaría por debajo del MTU para evitar problemas. Por ejemplo el script de python que uso para probar UDP, no puede manejar este tipo de paquetes, solo bajo por ejemplo a que tenga una carga útil de 1400 bytes trabaja de maravilla. Para esto le vería dos opciones, buscar como manejar este tamaño de paquete en el servidor, o comprimir los datos. Si ya tienes un programa servidor que soporta re ensamblar este tipo de paquetes entonces ya lo tienes listo.

[planeta9999]

Vale, gracias a ambos por los comentarios.
Voy a probar a partir los datos a enviar en paquetes de 1024 bytes, así cada matriz la troceo en cuatro pedazos y los envío uno tras otro en un bucle. Miraré en Wireshark, que esta vez se reciban todos los bytes.

Lo que me voy a encontrar en la versión final del programa que tengo que hacer es eso. El programa recibe unas animaciones que son frames de 4096 bytes cada uno, cada byte es un dígito de texto que va desde 0 hasta la F, todo eso se carga en una matriz, que cuando esta llena la tengo que enviar por UDP, y así constantemente en bucle.

Voy a mirar las funciones de manejo de cadenas en C, que es algo que lo tengo medio oxidado. La idea es trocear la matriz de 4096 bytes en cuatro trozos, enviarlos uno a uno, esperar 500 milisegundos y vuelta a empezar con la siguiente imagen recibida en la matriz. El cliente quiere una cadencia de envío de 2 imágenes por segundo, y poder configurar desde fuera (se lo pondré en un archivo de texto en SD) la IP de destino, el puerto y la velocidad de transmisión (imágenes por segundo).

[tsk]

Para observarlo coloca como filtro

ip.src==192.168.1.189

Vas a ver algo como esto

[planeta9999]

 

Ya lo tengo todo funcionando y va de fábula. Un kinetis MK64 enviando paquetes de 1025 bytes por UDP, el cliente me pidió añadir un byte a cada paquete para identificar el orden de los paquetes, del 1 al 4, cada cuatro paquetes es una imagen.

Hubo un poco de lío con si se envían los datos como campos "char" o "int", en principio enviaba una matriz de campos "char", pero parece que de esa manera los dígitos 0, 1, 2 y 3 no se reciben como el quiere, le van bien si los muevo desde un campo "int".

Supongo que un "0" desde un campo char envía el ASCII 48 del dígito "0", y enviar un 0 numérico envía el ASCII 0, o será al revés, menuda gaita con los char y los int. El caso es que si se lo envío todo desde campos "int" lo recibe bien.

El bootloader uTasker encriptado, funciona perfecto, después de resolver un pequeño problema con los parámetros de encriptación. El Viernes pasado ya envié unas cuantas modificaciones, colgando los archivos de MEGA y pasándole al cliente los enlaces de descarga por Whatsapp. Todo genial, si tengo un rato me gustaría configurar uTasker para los STM32, porque voy a usar un STM32F405 en el proyecto de la ruleta y me vendrá muy bien para poder dar también actualizaciones a distancia.

El chip W5500, fenomenal para gestionar comunicaciones Ethernet por SPI desde un micro.