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