> If it was discussed on this list: my apoligies, I could not find a > recent archive. Maybe you can send me a copy of the discussion.
It was, a while ago, I'm sorry though, I meant I'd been discussing it with people on IRC just last night. > I am a big fan of KISS, and my UDP based solution is amasingly simple, > much less critical from a security point of view, and it automatically > combines captures from several hosts. It is not quite as convenient as > the solution from winpcap, but I don't see the necessity of putting > everything in the GUI (at the expense of functionality). Yes, I agree we don't need to do a GUI or anything for this. The idea of capturing directly from a remote host is excellent. > Actually, I restart my remote process a lot more often than Ethereal > running libpcap. That is because the tracing is done inside of an > application program. The big advantage of using UDP is that I can > capture everything during the lifetime of the application. If the > application were a TCP server, I would always lose the startup phase > (been there, done that). Ah, in my case, restarting the remote capture units is highly undesirable/difficult/annoying to the users. > Three tier. That would solve all our problems, but it smells a bit > overengineered. On the other hand, it is exactly what I have been > doing. My middle tier is: > > cat /tmp/header <(nc -u -l -p 1234) > /tmp/fifo > where /tmp/header contains the pcap header. Writing a dedicated > application could make this a lot nicer. I currently have all this code written, actually, in a different form. For wireless IDS, Kismet supports multiple remote capture drones which capture from /N/ local interfacing (using anything supported, sometimes libpcap, sometimes custom capture code, depends on the platform), bundle the packet up with some custom layer1 signal info, and send it to all connected clients. The amount of bandwidth they do varies -- more than I'd want to queue uncontrollably. The localhost discussing came up because Kismet does a lot of specialty stuff -- mangling multiple capture headers (pcap, other, and multiple linktypes inside pcap) into a common format, decrypting WEP encrypted frames, etc. Theres a fair number of cases where people want to use that data in other apps, realtime. Currently Kismet can present a fifo named pipe, but that has lots of drawbacks -- blocking until the remote side is opened, and restarting when the remote side closes it. Having to restart the kismet drones or servers is often not acceptable to the users. So that explains where I'm coming from with, say, a TCP server on one side and libpcap as a TCP network client on the other. Being able to attach any pcap-aware application onto any other server-aware application lets us chain tools, which in some situations (like mine) is important. I'm almost envisioning a network protocol spec for this and maybe an example server, rather than the server code written entirely into libpcap. If libpcap is only the client, and we present a standard network protocol for sending data to libpcap, then all the custom apps that want to provide hooks can do so easily. > It would be very nice if the remote app could automatically filter out > its own traffic. In fact that may be the main advantage over tethereal > or tcpdump. pcap capture filter, not sure thats a big problem. Anyhow, my $0.02 -- perhaps my situation is more complex than yours, but I was already considering proposing a modification to do something like this once I'd ironed out the details, combining efforts would make a lot of sense if we'd like to try to include it in the libpcap distribution. -m -- "Typos are very important to the written form. They give the reader something to look for so they aren't distracted by the total lack of content in your writing." -- Davan
pgpncr1lA1cFF.pgp
Description: PGP signature
