On 7/4/05, Mike Kershaw <[EMAIL PROTECTED]> wrote: > I was actually discussing something similar to this just last night.
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. > I'd advocate swapping the client/server directions -- and probably, if > not always using, at least supporting TCP. I see it more as setting up > a remote capture system and then having a bunch of clients connect to > it. 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). > I think this is an important distinction, since otherwise you have to keep > restarting the remote agent every time you add a new client (bad) 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). > you have to set up some sort of listener on that end and ping it with a > UDP magic frame to start it sending (sort of annoying). No, it just keeps sending, as long as it is configured to do so. I could detect a buffer overflow and reduce the network, but for the low traffic link I am using that is not necessary. > My thought was a TCP server on the remote capture system (or in my case, > the local capture system too. 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 guess the big question is how much useability we want over something like > ethereal -k -i <(ssh -l root remote-name tethereal -w - ) and how much overhead and effort that requires. 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. > libpcap presents a select()able fd already, so we'd only have to write a > tcp client w/ a ring buffer and patch pcap_dispatch, I believe. With UDP you can even skip the buffer... :-) Thomas - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
