RE: Remote capture capabilities

["Fulvio Risso" <fulvio.risso () polito it>]

> -----Original Message-----
> From: Michael Richardson [mailto:mcr () sandelman ottawa on ca]
> Sent: giovedi 5 giugno 2003 20.22
> To: Fulvio Risso
> Cc: Invernizzi Fabrizio; tcpdump-workers () tcpdump org
> Subject: Re: [tcpdump-workers] Remote capture capabilities
>
>
>
> It doesn't matter that remote capture is turned off by default.
> Lots of things are off by default, but get turned on by various
> distros, etc.
>
> I'm sorry that I missed the thread before - I read a lot of lists.
>
> The problem is that once the code is accessible in a new remote
> way, the code
> will get invoked in new and interesting ways. This puts pressure on all
> of us to write better code - but it has to be something that we know
> we are doing.
>
> I haven't looked at your code - how do you transmit the filter
> specification?
> Now that it is crossing the wire, it can't mutate as easily.

No, it can change.
Currently we transmit bpf-compiled programs.
However, the filter has a "type" field, which can be used to send other
types of filters (e.g. literal strings like "ip and port 80").


> Is there any version control?

Yes.
Current version in "0" that means that this is not the "final" protocol.
It is highly experimental
If there is enough interest, we'll be very happy to improve it according to
the new requirements.


> As for divergence - it might be best if you guys went and experimented for
> awhile and reported back to us.

This is a better answer than what you said before.
I totally agree now.

        fulvio

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe