micro-ROS on STM32H743 established session with micro-ros-agent quickly ends

Nobody has claimed this yet.

Hello,

First of all, thanks for the very detailed tutorials and explanations. Thanks to all the information available online, I was able to sucessfully build a firmware on our stm32h743 board that runs and attemps a connection micro-ros agent (there was an issue with the udp transport example resulting in a deadlock on `LOCK_TCPIP_CORE()` but that's another story.

It feels like I am almost there, but I am encountering a new problem when the board attemps to connect to the micro-ros-agent. It seems that the board is sending unexpected data which results in micro-ros-agent shutting fown the session.

Please see debug below:


```
ros2 run micro_ros_agent micro_ros_agent udp4 --port 457879 -v6
[1707258505.140859] info | UDPv4AgentLinux.cpp | init | running... | port: 64663
[1707258505.140997] info | Root.cpp | set_verbose_level | logger setup | verbose_level: 6
[1707258509.430965] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 24, data:
0000: 80 00 00 00 00 01 10 00 58 52 43 45 01 00 01 0F 2A 2E D9 75 81 00 FC 01
[1707258509.431336] info | Root.cpp | create_client | create | client_key: 0x2A2ED975, session_id: 0x81
[1707258509.431443] info | SessionManager.hpp | establish_session | session established | client_key: 0x2A2ED975, address: 192.168.10.210:38908
[1707258509.431593] debug | UDPv4AgentLinux.cpp | send_message | [** <> **] | client_key: 0x2A2ED975, len: 19, data:
0000: 81 00 00 00 04 01 0B 00 00 00 58 52 43 45 01 00 01 0F 00
[1707258509.539450] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x2A2ED975, len: 36, data:
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0020: 00 00 00 00
[1707258509.539573] info | Root.cpp | delete_client | delete | client_key: 0x2A2ED975
[1707258509.539626] info | SessionManager.hpp | destroy_session | session closed | client_key: 0x2A2ED975, address: 192.168.10.210:38908
[1707258509.539636] warning | Root.cpp | create_client | invalid client key | client_key: 0x00000000
[1707258509.539873] debug | UDPv4AgentLinux.cpp | send_message | [** <> **] | client_key: 0x00000000, len: 23, data:
0000: 00 00 00 00 00 00 00 00 04 01 0B 00 85 00 00 00 00 00 00 00 00 00 00
[1707258509.643521] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258509.742010] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258509.842342] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258509.943190] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258510.042678] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258510.143645] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258510.243912] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258510.343683] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
0000: E8 03 00 00 00 CA 9A 3B C0 CB 17 07 00
[1707258510.444295] debug | UDPv4AgentLinux.cpp | recv_message | [==>> UDP <<==] | client_key: 0x00000000, len: 13, data:
```

I am seeing those packets being send by the board through the live debugger, which makes me think the problem is not due to a connection problem and likely resides on the board itself. I have zero knowledge of the underlying protocol thus zero understanding if these packets are normal at all.

I have been trying to debug the libmicroros lib itself to understand where these packets are coming from but sadly Platformio only shows the assembler for what's inside libmicroros, and I have no idea about how to add the symbols / sources to debug within the lib.

Thanks for your help in advance

Start with the UDP transport example for the STM32H743 and inspect the libmicroros entry points that produce the packets shown in the micro-ROS agent log. Investigate how to include symbols and sources for libmicroros in PlatformIO, then compare the board's transmitted data with the agent's expected protocol. Done means identifying the source of the invalid packets and documenting or fixing the connection failure.

Written by the indexing model from the issue text.