Tello. Whats possible?

[deadprogram]

Which port should be listened to for the responses? microlinux, please chime in.

 

[microlinux]

Which port should be listened to for the responses? microlinux, please chime in.

Responses from what, the API?

 

[deadprogram]

Yes, the API.

I already figured out that port 8888 was the correct one. So your python code works fine for me, thanks.

I am working on adding Tello to a our Go programming language framework Gobot. My WIP is here: hybridgroup/gobot

Almost working correctly, at the moment it only works if I run the Python code first.

 

[microlinux]

Yes, the API.

I already figured out that port 8888 was the correct one. So your python code works fine for me, thanks.

I am working on adding Tello to a our Go programming language framework Gobot. My WIP is here: hybridgroup/gobot

Almost working correctly, at the moment it only works if I run the Python code first.

Ok, cool. The local port is arbitrary. The Tello itself always listens on 8889.

If the Go code only works after running the Python code, my guess is that something is not working when putting it into command mode with Go.

 

[deadprogram]

Ok, cool. The local port is arbitrary. The Tello itself always listens on 8889.

If the Go code only works after running the Python code, my guess is that something is not working when putting it into command mode with Go.

The local port is arbitrary you say? How did you determine that, and also how does the Tello determine which port to communicate with?

 

[microlinux]

The local port is arbitrary you say? How did you determine that

Correct, this is the general nature of client-server communications.

how does the Tello determine which port to communicate with?

The source port is in the packet headers.

 

[Krag]

I was messing around trying to capture packets tonight and got a piece of an exchange. I have so far tried Packet Capture (nothing captured) Debug Proxy (nothing captured) and tPacketCapture. Only tPacketCapture seems to get any packets, I think because it is the only one of the three that captures UDP.

The problem with tPacketCapture is that the drone will not connect while it is capturing traffic. I _think_ this is because tPacketCapture doesnt support SSL. I managed to trick it by getting the App and the Drone connected and then starting the capture. It disconnected after a moment but before it did I captured a UDP exchange.

My guess is that it uses both UDP and TCP, probably that open TCP port. We need to find a capture solution that will do both.

As far as I can tell the phone sends a heatbeat to the Tello (192.168.10.1) UDP port 8889 every second. The Tello responds to port 6525 on the phone.

UDP Port 67 is news to me. I can't see anywhere where the code tries to open that port.

From looking at the code the video in port on the phone is UDP 6038 and the video transport protocol is RTP or something close.

Any help would be appreciated. I really don't know what I am doing.

 

[microlinux]

UDP Port 67 is news to me.

That's the DHCP server.

 

[deadprogram]

Correct, this is the general nature of client-server communications.



The source port is in the packet headers.

Sorry, let me rephrase my question.

The request is sent from ground station to Tello via UDP to Tello's well-known IP address/port. All good so far.
The response is sent from the Tello to the ground station via UDP to the IP address that was in the original request packet... but how does the Tello determine the port to use for the response?

 

[Splashy]

Looks like H264 encoded video accessed over rtp. Still having trouble finding out which port it comes in on.

 

[deadprogram]

I was messing around trying to capture packets tonight and got a piece of an exchange. I have so far tried Packet Capture (nothing captured) Debug Proxy (nothing captured) and tPacketCapture. Only tPacketCapture seems to get any packets, I think because it is the only one of the three that captures UDP.

The problem with tPacketCapture is that the drone will not connect while it is capturing traffic. I _think_ this is because tPacketCapture doesnt support SSL. I managed to trick it by getting the App and the Drone connected and then starting the capture. It disconnected after a moment but before it did I captured a UDP exchange.

My guess is that it uses both UDP and TCP, probably that open TCP port. We need to find a capture solution that will do both.

As far as I can tell the phone sends a heatbeat to the Tello (192.168.10.1) UDP port 8889 every second. The Tello responds to port 6525 on the phone.

UDP Port 67 is news to me. I can't see anywhere where the code tries to open that port.

From looking at the code the video in port on the phone is UDP 6038 and the video transport protocol is RTP or something close.

Any help would be appreciated. I really don't know what I am doing.
View attachment 140

Thanks for the pcap file, it is very interesting. Seems like there is a single response in there from the Tello.

What is the SSL connection that you are seeing form the other capture tools? I am very curious, since the Python lib from microlinux does not have any such requirement to function correctly.

 

[deadprogram]

Sorry, let me rephrase my question.

The request is sent from ground station to Tello via UDP to Tello's well-known IP address/port. All good so far.
The response is sent from the Tello to the ground station via UDP to the IP address that was in the original request packet... but how does the Tello determine the port to use for the response?

OK, I figured out that a side effect of the Python "bind" command being used for the same UDP socket, sets the senders local port. I achieved the same result in the Go code, and now it is working for me as expected. Thanks microlinux for working on the Python lib to provide some guidance for the rest of the community!

 

[microlinux]

The request is sent from ground station to Tello via UDP to Tello's well-known IP address/port. All good so far.
The response is sent from the Tello to the ground station via UDP to the IP address that was in the original request packet... but how does the Tello determine the port to use for the response?

The port that the request was generated from is in the header of the packet that was sent from the ground station. The Tello reads that.

User Datagram Protocol - Wikipedia

 

[microlinux]

OK, I figured out that a side effect of the Python "bind" command being used for the same UDP socket, sets the senders local port. I achieved the same result in the Go code, and now it is working for me as expected. Thanks microlinux for working on the Python lib to provide some guidance for the rest of the community!

Excellent!

 

[rjlouro]

With the help of a friend with a rooted phone we were able to extract the tcpdump of a connection to tello.

It connects to port 8889 of Tello, sends several UDP packets (some interesting replies on them, like build version, etc), and then we see the video UDP packets being sent to port 6038 of the mobile phone.

Tried to save just the video packets into a .pcap and load into VLC but no luck

First packet ever sent from the phone to Tello is a UDP packet with "E.conn_req:" followed by 3 more packets with unreadable data.
A reply is sent from Tello to the phone with "D.conn_ack:", and after that there are several UDP packets with unreadable data being exchanged, but there are some readable strings sent from Tello to the phone:

I.P.T.E....01.03.18.01
BUILD Mar 9 2018 21:48:07
DJI_LOG_V3
GP1_SQL

Tried to connect a laptop in the same network as Tello and mobile phone and open VLC to open any video stream out of Tello, but no luck. Maybe with a custom setup where the laptop would be a proxy between Tello and the mobile phone.

 

[deadprogram]

With the help of a friend with a rooted phone we were able to extract the tcpdump of a connection to tello.

It connects to port 8889 of Tello, sends several UDP packets (some interesting replies on them, like build version, etc), and then we see the video UDP packets being sent to port 6038 of the mobile phone.

Tried to save just the video packets into a .pcap and load into VLC but no luck

First packet ever sent from the phone to Tello is a UDP packet with "E.conn_req:" followed by 3 more packets with unreadable data.
A reply is sent from Tello to the phone with "D.conn_ack:", and after that there are several UDP packets with unreadable data being exchanged, but there are some readable strings sent from Tello to the phone:

I.P.T.E....01.03.18.01
BUILD Mar 9 2018 21:48:07
DJI_LOG_V3
GP1_SQL

Tried to connect a laptop in the same network as Tello and mobile phone and open VLC to open any video stream out of Tello, but no luck. Maybe with a custom setup where the laptop would be a proxy between Tello and the mobile phone.

Great work!

Any way to provide the packet dump itself, so we can all attempt to analyze it? I would assume probably that one of those packets contains whatever starts the video streaming.

 

[rjlouro]

Sure, here's the UDP stream for the communication between Tello and Phone.

Unfortunately the entire pcap is too large to upload to the forum, but I believe this is enough for now.

 

[deadprogram]

Sure, here's the UDP stream for the communication between Tello and Phone.

Unfortunately the entire pcap is too large to upload to the forum, but I believe this is enough for now.

Thanks!

 

[Krag]

Thanks for the pcap file, it is very interesting. Seems like there is a single response in there from the Tello.

What is the SSL connection that you are seeing form the other capture tools? I am very curious, since the Python lib from microlinux does not have any such requirement to function correctly.

In fact I am not seeing any SSL connections. My only reason for thinking it is SSL is that it disconnects when I start capturing. There could easly be something else going on.

 

[Krag]

With the help of a friend with a rooted phone we were able to extract the tcpdump of a connection to tello.

It connects to port 8889 of Tello, sends several UDP packets (some interesting replies on them, like build version, etc), and then we see the video UDP packets being sent to port 6038 of the mobile phone.

Tried to save just the video packets into a .pcap and load into VLC but no luck

First packet ever sent from the phone to Tello is a UDP packet with "E.conn_req:" followed by 3 more packets with unreadable data.
A reply is sent from Tello to the phone with "D.conn_ack:", and after that there are several UDP packets with unreadable data being exchanged, but there are some readable strings sent from Tello to the phone:

I.P.T.E....01.03.18.01
BUILD Mar 9 2018 21:48:07
DJI_LOG_V3
GP1_SQL

Tried to connect a laptop in the same network as Tello and mobile phone and open VLC to open any video stream out of Tello, but no luck. Maybe with a custom setup where the laptop would be a proxy between Tello and the mobile phone.

Good stuff! So you were able to capture using tcpdump? I had not heard of that method. Something like this I assume:
Debugging with tcpdump and other tools | Android Open Source

The dump you sent also confirms that the flightlogs/.DAT files contain raw packet data from the drone. You can see those strings like "DJI_LOG_V3" in there.