Analysing a Network Protocol
gpredict
is piece of software for tracking things in orbits, sometimes you
want to automatically point things at stuff in orbit. To get things pointed at
stuff in orbit we can use a rotator controller,
gpredict
as a piece of radio
software has an antenna rotator controller built it. The
gpredict
rotator
controller expects to speak to something over TCP.
I have not been able to find documentation for the protocol (I didn't look very
hard), I thought it would be fun to reverse engineer the protocol and write a
simple daemon.
Earlier
I took some first steps to see what
gpredict
was
doing on the network.
If you want to play a long at home this is what I am going to do:
- set up a dummy daemon using netcat (nc -l localhost 4533)
- use tcpdump with -XX to watch all traffic (e.g. tcpdump -XX -ilo0 tcp and port 4533)
- send data from gpredict to the daemon (hit the 'engage' button on the antenna control screen)
- play with responses (type into the console running nc)
- look at the gpredict code starting here: https://github.com/csete/gpredict/blob/master/src/gtk-rot-ctrl.c
The Network traffic
$ nc -l 0.0.0.0 4533
p
P 180.00 45.00
When I press the 'engage' button,
gpredict
sends a single lower case 'p', if
I press enter, sending a blank line,
gredict
responds with a capital 'P' and
two numbers. To me these numbers look like an Az El pair, they correspond to
the values on the antenna control screen in
gpredict
. No need for
tcpdump
this time.
We have source avaialble
With only one half of the network protocol to look at, we can't get very far.
gpredict
is open source and there is a
github
mirror where we can browse
the source tree. The file names in the 'src' directory show some promising
results:
gtk-rot-ctrl.c
gtk-rot-ctrl.h
gtk-rot-knob.c
gtk-rot-knob.h
rotor-conf.c
rotor-conf.h
sat-pref-rot.c
sat-pref-rot.h
The pref and conf files, are probably configuration stuff, I have no idea what is in the knob file, but the gtk-rot-ctrl set of files is what we want. I confirmed this by picking a string in the UI of the relevant screen and grepping through the code for it. This can be troublesome if the software is heavily localised, but it this case I could track down the 'Engage' button to a comment in the code .
There are two functions used for network traffic,
send
is used to send data
into a tcp connection,
recv
is used to receive data from a TCP connection. If
we can find these in the code, we find where the software is generating network
traffic. Normally only a starting point, it is very common to wrap these two
functions into other convenience functions.
A grep through the code brings up a
send
call
in
send
rotctld
command
. More grepping and we find that
send_rotctld_command
is called from two places, the
get
pos
function
(which I have to guess asks for the rotators positions) and the
set
pos
function (which must try to set the rotators position).
The
get_pos
function fills a format string with "p\x0a" and uses
send_rotcld_command
to send it. Looking up 0x0A in an ascii table shows it is
Line Feed(LF) also known as a newline on a unix system. It splits
buffback
on
newlines using
g_strsplit
, looking to find two floating point numbers to
use as azimuth and elevation, one on each line.
get_pos
:
/* send command */
buff = g_strdup_printf("p\x0a");
retcode = send_rotctld_command(ctrl, buff, buffback, 128);
...
vbuff = g_strsplit(buffback, "\n", 3);
if ((vbuff[0] != NULL) && (vbuff[1] != NULL))
{
*az = g_strtod(vbuff[0], NULL);
*el = g_strtod(vbuff[1], NULL);
}
This piece of code shows up something really important,
gpredict
is using a
single function to both send a command and gather the response from the remote
end. If we look at
send_rotctld_command
the
recv call
is called right
after a send. Here we can see that
gpredict
only does a single
recv
to
gather responses, it is expecting a reply that fits into a single read. This is
a bug, but probably not one that really matters.
/* try to read answer */
size = recv(ctrl->sock, buffout, sizeout, 0);
The
set_pos
function fills up a format string with a capital 'P', and two
floating point numbers. It doesn't do any parsing of the response, only looking
at the error code from the socket call.
set_pos
:
/* send command */
g_ascii_formatd(azstr, 8, "%7.2f", az);
g_ascii_formatd(elstr, 8, "%7.2f", el);
buff = g_strdup_printf("P %s %s\x0a", azstr, elstr);
retcode = send_rotctld_command(ctrl, buff, buffback, 128);
Write a Daemon
With this little bit of analysis we have enough to write an antenna control
daemon that
gpredict
can speak to. The rotator control protocol has two
simple commands, a position query which expects the currect az/el across
separate lines and a position setter, which expects no response.
#!/usr/bin/env python
import socket
TCP_IP = '127.0.0.1'
TCP_PORT = 4533
BUFFER_SIZE = 100
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((TCP_IP, TCP_PORT))
s.listen(1)
conn, addr = s.accept()
print 'Connection address:', addr
az = 0.0
el = 0.0
while 1:
data = conn.recv(BUFFER_SIZE)
if not data:
break
print("received data:", data)
if data == "p\n":
print("pos query at az:{} el: {}", az, el);
response = "{}\n{}\n".format(az, el)
print("responing with: \n {}".format(response))
conn.send(response)
elif data.startswith("P "):
values = data.split(" ")
print(values)
az = float(values[1])
el = float(values[2])
print("moving to az:{} el: {}".format( az, el));
conn.send(" ")
elif data == "q\n":
print("close command, shutting down")
conn.close()
exit()
else:
print("unknown command, closing socket")
conn.close()
exit()
Using the
python TCP server
example as a starting point it is easy to put
together a daemon that will listen to the rotator controller. The code should
be pretty straight forward to read, we process the commands documented earlier.
There is one addition that I didn't see in the code at first. There is a quit
command that does not use the normal wrapper and instead uses
send
directly.
This command was easy to handle.
This is how I approach network problems, whether in code I have written or code that is completely new to me. Hopefully if you have been following along at home the example above is straightforward to read.
