> > 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.
IMHO thats capture drone application level dependent -- whomever is writing the server can define how it will operate. I know I couldn't support arbitrary restarting, due to how I drop privileges its a one-way road once the initial interface binding is done. Remember we'll have local as well as remote capture systems. (Of course I'm not the only person looking to use that code, but I imagine there will be others with similar problems.) > > 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. Perhaps a "libpcap server" library for sending the data? Or maybe thats over-engineering it and we should just define the protocol and provide an example server. > 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. Well, it would matter since the server code would have to be embedded into other applications -- for example, I need to know what the protocol is so that I can write a server module into Kismet to send the pcap stream over TCP. For pure remote-capture it's a closed system, but why limit ourselves? > 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. Depends on the drivers, which is part of why I have a 3000 line whack of pcap capture code to transform it into a local format. On linux the 802.11 drivers have 3 different headers they can use, *BSD adds another official header and 2 "random crap the driver throws out" forms, OSX airport classic uses some memory copy stuff and doesn't do pcap at all, and one embedded device sends a UDP stream. Sprinkle "supporting L1 radio signal info" liberally among that (but not on all) and you get the idea. > 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). Yes, tentatively, we've got 3 tiers, even though 1 and 2 would often be one application. (capture, serve as drone, capture, mangle, serve as more complex application). tier 3 being the "client" which is any pcap-aware application capturing from the remote system. > 3 parts have to be implemented: libpcap reading from a TCP connection, > the multiplexer and an prototype capture drone. s/multiplexer/server code/ anyhow. > There are two network protocols to define, although I would propose > libpcap for both of them. 2? pcap would be the packet data format, the protocol itself would need a little bit more on top of it -- a version/linktype header frame and organizing the contents of the pcap struct appropriately so we can read the length of the frame at the beginning easily. Anyone else have any opinions? Otherwise I can probably spec out at least a rough version of it tonight. -m -- the sand remembers once there was beach and sunshine but chip is warm too
pgpzWnMvR6P3g.pgp
Description: PGP signature
