Howto:Record, analyze and replay multiplayer flights with network tools

From FlightGear wiki
Revision as of 11:22, 17 February 2013 by Jano (talk | contribs) (→‎tcprewrite magic: start of the paractical exemple)
Jump to navigation Jump to search
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

intro

This page will talk about the usage of networks tools, applied to FlightGear, by working on the udp packets sent by mp.
It will cover some use in mp problems diagnostics, and a way to record (and replay) a mp session.
The truth is I never found what i needed in FG itself, but just a few work with some networks tools made my day .
I agree this isn't easy to use, need some time to master the tools, and root access to the network interface (so take care ;) ), but it works, as can be seen in this video!
Some exemples of utilisation:

  • debriefing/training of formation flight: your aerobatic formation can review the flight, and find who broke the diamond figure in the top of the loop :) You can even flight again with the recorded mp flight to improve your skills.
  • make a film by recording the planes one by one, without any internet connection.
  • having some "mp action files" available, eg to replay them in a FG démo, or if you don't have internet but want some other planes than the silly ai models.
  • save a meeting, and do video capture after the event, this way you can make multiple video takes, and do a nice editing.
  • udp traffic analysis, to see the effect of internet transmission on other mp pilot's packets (loss/jitter)

tools

  • Wireshark: a network flux sniffer/analyser, available for all plateformes, we will use it to record the FG udp traffic.
  • tcpreplay: a suit of programmes, available on mac and linux, and maybe on windows by using Cygwin. Will be used to change some udp packets properties, and to send back the traffic to an other FG session.

capture FG network traffic

Assuming we are connected to a mpserver, and that the server and your FG session receive on udp port 5000, we can record all the udp packets going to a port 5000. This way we will record our outgoing packets, and the ingoing packets from the other mp pilots.

we start Wireshark, then select the network interface used, and finally set a filter and apply it, eg:

udp.dstport == 5000 && !(icmp.type)

finally, we stop the capture and save the file as a .cap.

What do we have now?
We have the flight recorded at the network level!

With only wireshark, we can now extract only some pilot(s), keep only a time interval of traffic, or see some traffic properties.
With the help of tcpreplay/tcprewrite, we can sent the mp traffic back to a running FG session.

pilot individual file

In Wireshark, it is possible to extract each pilot flight individually, the filter to use looks like:

frame contains "callsign"

and to exclude a pilot:

!frame contains "callsign"


This way you can have each pilot flight separated, and if needed, you can merge again 2 or more pilots in a file, eg you have recorded a diamond formation, and you want to practice the left wingman position, either you remove the existing one for the .cap, or you merge the 3 others again, after having done individual .cap.

Wireshark come with mergecap, to merge multiple .cap file, and taking care the chronological order is respected.
The provided editcap can be used too, if you need to add a time offset to a plane, to address latency recorded issue.

It's sometimes difficult to have lot of matching shedules, when you are training in an aerobatic team, and we have here a good way to train with other mp pilots without being connected. You can even practice by file exchange, the leader make a flight, send the .cap to the second, wich add his flight, then pass to the 3 etc...

udp packets loss/jitter

Here's a wireshark analyse, showing the mp packet rate for different mp pilots, from a recorded mp session.
received mp packet rate

  • the black curve got a nice 10 packets/s, our internet link was good, maybe connected to the same mp server.
  • red and pink were pretty choatic, their packets are often lost, and i guess they are jittery in FG. they were probably connected to an other mp server.
  • blue and green show less than 1 packet/s, this can be explained by some misconnexion between servers, by default the mp server send at 1fps to the other mp server, just to "inform" them wich planes they host, and they start relaying all the packets once other mp server send them plane in vicinity. In this case probably our server didn't relay to their, and we only got the "lazy relay" from their server.

replay the flight to our FG session

Ok, we have a recorded flight saved as .cap file, and we want to see it again in FG. That's where the tricky parts start :)

tcpreplay limitation

To make things short, tcpreplay can not send directly to fg, if we are on the same computer.
Until now I use a other PC to send the traffic back to my FG PC, if you find an other way, tell me :) .From the tcpreplay FAQ, it could work if tcpreplay run in a virtualised machine, but i didn't gave it a go.

tcprewrite magic

Next is that the udp packets, to come back to our PC, need some editing in the udp packets:

  • the mac address of the sender must match the mac of the PC sending the recorded flight.
  • the destination mac address must match the receiving PC, or depending the case the router's mac address.
  • the destination and sender IP address must match the IPaddress of the 2 PC involved.

We make the change in one go with tcprewrite, here's a practical exemple:

we have:

  • the computer running FG, mac address 00:11:22:33:44:55, ip address 192.168.1.12 .
  • the computer we will use to send the recorded packets: mac address 99:88:77:66:55:44, ip address 192.168.1.17

It's up to you to find your mac and ip address, you can use wireshark on some network traffic between the 2, or ifconfig on linux etc...



---stay tuned---