On 7/4/05, Mike Kershaw <[EMAIL PROTECTED]> wrote: > Ah, in my case, restarting the remote capture units is highly > undesirable/difficult/annoying to the users.
Ok, but that depends on the application. I think it would be nice to support easy restarting of remote capture processes, especially if there are many of them. > 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 Yes, that it pretty much what I do at the moment, and the named pipe is very ugly. It has two main problems, imho: no concept of a connection, and no multiplexing for several readers. So using TCP should be a significant improvement. > 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. Fine by me. And libpcap would not send on the TCP connection? So it is still a lot easier than rpcap. > 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 reads the connection, the format does not actually matter, because it is not exposed. On the other hand, I don't see much reason to deviate from the libpcap format. Do you have a document for the layer 1 encapsulation? I am looking for an existing dissector in Ethereal that I could use for my purpose (because I am lazy), but I have not found anything promissing. Linux cooked looks ok, but I can't get it to recognise MTP3 (SS7) frames. So to recap the discussion: we have a 3 tier architecture, with a "capture multiplexer" in the middle. Libpcap can connect to this multiplexer via TCP. Capture drones can connection to the multiplexer using TCP (or UDP in my case). 3 parts have to be implemented: libpcap reading from a TCP connection, the multiplexer and an prototype capture drone. There are two network protocols to define, although I would propose libpcap for both of them. > 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. Yes, very nice :-) Thomas - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
