We already got some hints and clues within our last packet inspection about a possible drone-rotation command. However, the reverse-engineering process is quite intense as too many unknown variables are in the game. Thus, we require a better overall strategy for this project.
The DJI Protocol – Packet Types page will fully feature all known packets, including their identifier, a short description and the payload length. This page will act as the table of contents for the entire project. Moreover, each successful reverse-engineered packet will receive its dedicated page; also linked within the table of contents.
The “daily” reports (as this one) will remain and summarize all accomplishments throughout the day, including not only gained knowledge, but also encountered fails. With that said, let’s continue with the actual status report.
Mid-flight reverse-engineering tool
The reverse-engineering process features currently following steps
- Set up a hotspot and connect the smartphone
- Turn on the drone and establish a connection
- Start tcpdump to capture packets
- Manipulate the drone with the DJI smartphone app
- Stop capturing packets
- Open the .pcap file with Wireshark and remove “noisy” packets
- Go through the leftovers and compare each and every bit
This progress is quite excessive and time-intensive; compared to the gained knowledge. In addition, we can’t link our drone manipulations directly to the dump, as step 7 happens way after the drone has been shut down. Our conclusion: We require a custom reverse-engineering tool which renders step 3-6 obsolete and facilitates mid-flight live “debugging” and packet analysis. The software should capture the UDP packets, run them through a customizable filter and display the result-set on screen.
Since I do the most part of the work on Linux, the tool requires to be platform independent. As WPF counts to my personal strengths, Avalonia comes in pretty handy. Their WPF similar XAML definition and congruent MVVM pattern speeds up the development, as I do not require to learn a new framework completely from scratch. As far as I could conclude Avalonia is actually a port from the Microsoft Silverlight toolkit. Plus side: it not only works on windows, but also on Linux and Mac. I will upload the entire project on Github later on, so stick around for any updates.
The last days we build the core-part of the software, which comprises following features
- UDP Packet Listener
- Logging Packets to a .pcap file
- DJI Packet-Structure, extended from day 4
- Panels to display packets
- Filters for live-analysis
- Copy and Paste Hex values
Time will tell what kind of features we are lacking, so the plan is defined to extend the tool from time to time. With the tool in our pockets, we started a day trip into the wilds to capture our first live packets. However, we came across yet another difficulty: We never flew the drone before – all the previous captured packets originated from an on the ground drone. We started our hotspot, connected the drone and started hovering 1.5m above the ground. Roughly after 10 seconds the connection had been lost. (Luckily the drone has an emergency plan for such a scenario: Initiate immediate landing) We came to the conclusion that the mobile network-card hasn’t enough throughput or the Wifi signal wasn’t strong enough. To tackle those issues, we have two counter measurements:
- 300 meter Wifi – Extender: Was the issue signal strength related?
- External Wifi Adapter: Was the issue network-card related?
The notebook’s network-card still has to handle the communication between the operator and the Extender, but the signal-strength shouldn’t be an issue anymore. During our second test-flight (which did take way longer than 10 seconds,.. yeeeee) the singal had been lost after roughly 30 seconds. (Still hovering next to the extender!) Compared to the non-wifi-extender flight, the drone image-feed was still available, but the mobile-app did report signal lost nevertheless. Inputs on the operator were delayed or haven’t been accepted at all. Our current assumptions:
- Packet sniffing slows down the communication
- The network-card isn’t capable of handling two active connections (operator + wifi-extender)
External Wifi Adapter
To elaborate whether the network-card or the packet sniffing may cause the issue, we bought an external USB-Wifi Adapter, which is capable of 2.4-5GHz and features over 300Mbit/s. Thus, we can not only operate the drone on 2.4GHz, but also at 5GHz. In addition, this enables several possible networking scenarios which require some additional benchmarking, in order to choose the best network configuration.
|Scenario||Download [Mbps]||Upload [Mbps]||Ping [ms]||Jittering [ms]||Packet loss [%]|
- create_ap internal internal Operator 12345678 -c 2 -w 2
- create_ap external internal Operator 12345678 -c 2 -w 2
- create_ap internal external Operator 12345678 -c 2 -w 2
Retrospectively, it does make sense that the drone lost connection with the notebook on our first try. With a 1Mbps bandwidth and almost 30% packet loss the connection is too unstable. Moreover, the drone operated on 4Mbps, which has never been reached while performing the benchmark. Scenario 3 offers the highest bandwidth, but fails in terms of packet loss and jittering. Since the drone’s communication bandwidth can be limited to 1Mbps (upsi), we will stick with the second scenario, offering the highest stability in terms of jitter and packet loss, while providing more than enough bandwidth. Side note: the benchmark has been performed while sniffing packets with Wireshark.