Hi!
(I’m not shure that this is the wrigth category, but I did not find a better one)
I have some understanding questions regarding the actual mavlink telemetry implementation:
- In rx_functions.sh, a virtual com port /dev/openhd_mavlink2 is created. This virtual port connects the wfb telemetry uplink to /usr/local/bin/mavlink-routerd -e 127.0.0.1:14550 /dev/openhd_mavlink2:115200 & … that’s seems clear to me.
- As far as I can see, the udpsplitter.py does forward an udp stream from / to port to several IP without doing any else, that’s wright? So udpsplitter.py is used to distribute udp to several IPs?
telemetry uplink → telemetryfifo2 → socat → udpsplitter → downlink? But what downlink?
- So far I can see, telemetry link uses virtual com ports, but also various named pipes?
I’m asking, because I want wo implement two things:
- Message signing for Mavlink2, because not all ground stations implement this. Without signing, there is a serious security flaw at the moment (as far I can see). Maybe later we can encrypt the whole mavlink stream, but this is a second step.
- Second, for trackers like U360GTS I want to insert some kind of mavlink filter (I’ve already have some C++ mavlink fiter written for another project), that uses a Mavlink2 stream and outputs only the tracker relevant messages as Mavlink1 to the tracker. That’s because the U60GTS cannot work with Mavlink2 correctly and has a problem with unfiltered high bandwidth Mavlink streams.
Thank you very much,
Stefan
Hey 
Downlink is piped through a couple FIFOs to distribute telemetry to various things, one of them sends the telemetry straight out of the UART pins on the ground and isn’t exclusively for Mavlink. Another is wired to a virtual serial port.
The virtual serial port is there because the uplink and downlink are 2 separate streams from 2 different processes at the moment, the virtual port combines them in a way that mavlink-router can treat as a single serial port. UDPsplitter is only involved in single direction streams like video.
When a device connects to the hotspot it will trigger mavlink-router to start sending it telemetry, which allows the hotspot device to notice where the stream is coming from so it can send messages back to the same port it came from.
The telemetry handling is being rewritten at the moment and that stuff is partly why
Mavlink signing is only supposed to be used on the endpoints, interpreting it along the way and rejecting messages even when they can’t be authenticated would be a violation of the Mavlink routing rules:
- forward a message according to normal rules even if it cannot be authenticated (or even understand) and hence cannot be processed locally.
Encryption is being added though.
It sounds like U360GTS is going to add Mavlink2 support anyway, I see someone has been maintaining a fork with support added. If they still haven’t merged that in the official releases when our newer telemetry stuff is merged, I’ll add an option to restrict the output in the ground station.
This is the part of your answer I do not understand
I’m thinking of a simpler solution, because for Ardupilot you just have to sign the uplink messages and let the FC do the handling. Downlink messages from Ardupilot are not signed as far as I know. This would be a simple increase in security. But that all would be not necessary if a encryption is planned.
The encryption i.e. used by svpcom seems to add significant higher drop rates due the message aggregation there. I do not know at the moment, how good (or bad) a encryption with chacha20 or libsodium will impact packet drop rate.
As far as I can see, at the moment there are 2 different „channels“ for telemetry. One on port 3, that uses rx_rc_telemetry to receive rc and telemetry and routes it directly via UART to the fc on the air side.
The other channel is on port 30 and uses rx_rc_telemetry_buf and microservices. Am I right so far?
Telemetry coming from ground, from a attached GCS, uses the tx_telemetry / port 3 / rc_rx_telemetry way from ground to air?
I‘ve written a small patch that encrypts the mavlink uplink with libsodium. If there ist any interest, I‘ll publish it.
But this 2 way mechanism irritates me a little bit at the moment. What kind of telemetry is uplinked on port 30? On my test installation I can mainly see heartbeats?
Thanks,
Stefan
Port 30 is either the uplink or downlink for microservices, there’s a couple of them so there are a few heartbeats yes. They’re very tiny and infrequent compared to the other streams but we’re still going to have them all respect a “radio silence” mode when the vehicle is armed soon.
Thank you for your answer. Can you a little bit more precise? Or is there any documentation besides the source code?
Telemetry-> “old rodizio named pipes” (Port 3) parallel to → microservices (Port 30)?
Is there any cause to solve this on that way, or is this just historical?