mirror of
https://github.com/alice-lg/birdwatcher.git
synced 2025-03-09 00:00:05 +01:00
73 lines
2.4 KiB
Text
73 lines
2.4 KiB
Text
|
Here's a small writeup of our findings in BIRD so far.
|
||
|
|
|
||
|
|
Barry O'Donovan, INEX - the company behind IXP Manager. Wants to do
|
||
|
|
PHP screen scraping of the BIRD client to create an API to BIRD.
|
||
|
|
|
||
|
|
His API design:
|
||
|
|
|
||
|
|
https://github.com/inex/birds-eye-design/
|
||
|
|
|
||
|
|
https://github.com/inex/birds-eye-design/blob/master/v4-show-protocols-all
|
||
|
|
|
||
|
|
We investigated a better way of doing the API so we don't have to run
|
||
|
|
PHP on the routeserver. Is there a specified protocol between the BIRD
|
||
|
|
client and daemon? Daniel and I had a look here:
|
||
|
|
|
||
|
|
git://git.nic.cz/bird.git
|
||
|
|
|
||
|
|
specifically the branch "client-next" which has seen some action
|
||
|
|
regarding the client/server protocol and looked at it. It seems there's
|
||
|
|
not much of a formal definition of the protocol.
|
||
|
|
|
||
|
|
Client connects with a unix socket through, client.c:server_connect(),
|
||
|
|
then they just send whatever commands they get from the CLI and the
|
||
|
|
entire command is parsed by the *server*! Replies are prefixed by a
|
||
|
|
return code but that's basically it for specification of the replies!
|
||
|
|
|
||
|
|
Client connects with a unix socket, client.c:server_connect(), using a
|
||
|
|
global variable server_fd for all communication. The Unix socket is
|
||
|
|
called something like bird.ctl, typically /var/run/bird.ctl.
|
||
|
|
|
||
|
|
A simple
|
||
|
|
|
||
|
|
% nc -U /var/run/bird.ctl
|
||
|
|
|
||
|
|
gives access to the server directly! However, not a well specified
|
||
|
|
protocol. There is, however, client/reply_codes.h:
|
||
|
|
|
||
|
|
/*
|
||
|
|
Reply codes of BIRD command-line interface
|
||
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
|
0xxx Action suceessfully completed
|
||
|
|
1xxx Table entry
|
||
|
|
2xxx Table heading
|
||
|
|
3xxx Internal messages
|
||
|
|
8xxx Run-time error
|
||
|
|
9xxx Parse-time error
|
||
|
|
<space> Continuation
|
||
|
|
+ Spontaneous printout
|
||
|
|
*/
|
||
|
|
|
||
|
|
but no real protocol. You have to parse everything after the reply
|
||
|
|
codes from the position, no better than screen scraping from the
|
||
|
|
client.
|
||
|
|
|
||
|
|
An interesting option might be to look for all the response generator
|
||
|
|
in the code which returns the replies and instead generate JSON
|
||
|
|
directly instead of sending free form text.
|
||
|
|
|
||
|
|
All output through the server/client interface is probably done with
|
||
|
|
cli_msg() and it seems many of command output is from nest/*.c and
|
||
|
|
proto/*.c and sysdep/*.c.
|
||
|
|
|
||
|
|
The actual grammar for the CLI commands is done in Bison .y files.
|
||
|
|
Look for CF_CLI() to see what functions the actual commands run. Then
|
||
|
|
you can go to these command functions and generate, say, JSON as
|
||
|
|
output instead of using the more freeform cli_msg().
|
||
|
|
|
||
|
|
You might use
|
||
|
|
|
||
|
|
% git grep -A 1 "CF_CLI("
|
||
|
|
|
||
|
|
to find them all.
|