Hi,
I started working on the packet assert test this week, that we discussed
earlier
and we discovered, that the idea of packet capturing might have much broader
use in LNST.
Jirka had an idea, that we could put an optional parameter to the
controler to
enable debugging mode, in which communication on all interfaces would be
captured by tcpdump, logged and then transfered back to controller along
with the logs.
This could also be useful along with tcpreplay to catch and reproduce some
particularly sneaky bugs. tcpreplay can be run as an exec from command
sequence to simulate previous situation within the network in later recipe
runs.
I tried to figure out a way to implement this efficiently, but I can't
really come
up with a straight-forward solution at the moment. We could use tcpdump
to create a *.pcap dump file for each interface and then analyze it with
capinfo (it's a part of wireshark) or again with tcpdump to get some
information.
Or there is a option to bypass tcpdump and use libpcap directly through some
of it's python bindings (pypcap, pcapy or pylibpcap) along with dkpt
library for
parsing packets, but I'm not sure what's the current state of development of
these things and how stable they are.
I guess we could start simple with tcpdump and optimize it later in case
some
performance issue comes up.
I also looked at tcpdump's code at how they parse the packets' headers into
strings and, they have separate C modules for every supported protocol type
(called print-<protocol_name>.c), so they are not using any library that
we could
use easily.
Then there's a native capture tool for python called "scapy", but it's
supposed
to be very slow and buggy (as of what I read about it, I haven't tried
running it).
The interface in LNST then could look like this:
<netconfig>
<netdevice id="1" type="eth" phys_id="1">
<addresses>
<address value="192.168.122.225/24" />
</addresses>
<capture enabled="true">
<options>
<option name="filter" value="tcp" />
<option name="format" value="binary" />
<option name="keep_log" value="true" />
<option name="stats" value="true" />
</options>
</capture>
</netdevice>
</netconfig>
This config would enable capturing with custom filter to get only tcp
traffic, it would keep
the log when the recipe is done and transfer it back to controller (the
log option) and
controller then would read all the files with capinfo and printed some
stats.
At first, I thought that the stats should be gathered periodically as
the packets come
in, but it's rather ineffective to bring each packet through an
additional process, that
would have to run and count them, when we can do this later in
postprocessing
where performance is not an issue anymore.
What do you think? Is this reasonable?
Radek
Show replies by date