ROS service TCP packet structure
Is somewhere in documentation stated the structure of a TCP packet used for persistent service communication? I deduced, that last bytes correspond to service arguments (or response values), however the rest is a undecodable for me.
I want to sniff (tcpdump) TCP packets sent by ROS service between two nodes. However, I need the detect correct packets from all packets sent by a node, so I think I need to locate bytes, which uniquely identify the service. But where they are and where I can find the signature of the specific service? I tried to locate md5 sum, but it is not there.
Thank you for any hints, I know, I can spend many hours reading the source code to understand in detail, how serialisation works in ROS, but a simple packet structure would be a huge help to me.
IIRC, Wireshark has a dissector for ROS traffic built-in for a few years now. I'm not entirely sure whether it supports services though, but that would be easily checked.
Edit: this one: TCP based Robot Operating System protocol (TCPROS).
Thank you for pointing to this option! However, it does not decode ROS services.
Afaik services use
TCPROSas well, so I'm curious why it wouldn't dissect it.Edit: testing it a bit, it does seem to be able to dissect the request header, but not the payload. Perhaps it doesn't support or achieve reassembly of the stream properly:
As to whether there is a "simple packet structure": afaik there is no single document which describes that. Perhaps wiki/TCPROS comes closest.
Though this is true only for service connection initialisation (every time for non-persistent services, but only once in the beginning for persistent ones). So for my usecase (starting to listen in the middle of the communication), it does not help. But it is good to know, wireshark provides dissection of some ROS messages.
So if you don't know the service types involved, how would you go about dissecting the data? Service payload doesn't seem to include any indication of the layout of the data, which seems to make dissection difficult.
I do know the service type. But for persistent TCP service connection, only first packet contains the header and I am not guaranteed to catch it (most of the times I will not). So my goal was to dissect ROS service message WITHOUT header (which persistent services do not send) of known service. Or at least get some service-unique part...
For me, it is enough to recognise the packet among others (to sniff all packets of one service). Since the service packet is quite long (~ 70 bytes + payload), I supposed there are some bytes telling of what service this packet belongs to (since in one ROS node, more service servers can operate). So far I did simple packet difference and located bytes, which change on different ROS runs for the same service, but that's far from perfect. I also tried to use service URIs (to catch only packets between two ports - client and server), however client port is harder to obtain, can change and this approach is useless for more clients.
Maybe I get a bit off topic in here, but it is a background motivation for my question.
well that helps. But from what I remember/saw, plain payload of service invocation does not include any indication of which service type is involved. Interpretation of bytes is dependent on external/prior exchanged information between client and server.
Is it really possible to dissect the data without having witnessed the session setup?
is this always the case? The
AddTwoIntsservice I tested above has a payload of around 24 bytes I believe (a,band some other number).yes, so that's what I was referring to. If you miss out the header, the rest if just "random" binary data.