Hello Amir, let me share some thoughts with you about the first two issues: a) how to import flow-tools files in nfacctd and b) the stale print plugin. I'm not a flow-tools guru, so comments are warmly accepted by anyone will have a better solution or will notice any error on my side. And let me excuse for such a long email.
a) i see two candidates to let flow-export feed data to nfacctd: the -f1 (pcap format export) and the -f4 (wire format - as you pointed out). The f1 is defined an hack and seems to be greatly limited; instead, the f4 (giving a look to the source code), seem to recreate NetFlow packets stripped of any valid IP/UDP header and missing any kind of delimiter. I don't see f4 this useful (even because as you noticed, you know nothing about the length of what is streamed out) and i've been unlucky while googling a bit for any practical application of it. Said this, i was thinking that maybe a better way to join the two tools could be the flow-send way: it's tailored to send NetFlow packets full of their headers (and should also be able to spoof the IP address of the "original" router) over the network; then, it should be matter of selecting the loopback interface. The method allows to not get slower (than the stdout/stdin) and avoids ugly buffering issues and hacking both source codes. a1) a problem still remains (and is closely related to point b which will get discussed later): flow-send will nicely exit as soon as its finished with his job while nfacctd will still behave as a daemon: it will lie in background, waiting for new packets to come. I see two solutions to this: 1) the interactive way: two terminals are opened, one to fire nfacctd, the other to fire flow-send; flow-send finishes and the human terminates nfacctd by pressing the usual CTRL+C; 2) a simple shell script that fires both tools (in its simplest form it can launch nfacctd into the background and flow-send in foreground) and as soon as flow-send is finished, the "killall -INT nfacctd" is sent in order to correctly terminate nfacctd. b) print plugin lies undefinitely into its core loop because nfacctd does not contain any support for "files". If you give a look to the source code of the freshest tarball i've sent you (it's actually at http://www.ba.cnr.it/~paolo/pmacct/pmacct-0.9.4-20051017.tar.gz ) pmacctd behaves differently when it knows it's reading from a file: when it encounters the EOF it takes the exit lane and notifies this to the attached plugins: pmacctd.c:471 if (config.pcap_savefile) { fill_pipe_buffer(); sleep(1); stop_all_childs(); } In order to read from files, nfacctd needs an exit lane like the one above in order to stop the plugins (in the end, it's the unique to know it has just reached the EOF). Cheers, Paolo
