[Winpcap-users] rpcap protocol
Fulvio Risso
fulvio.risso at polito.it
Wed Jun 29 05:35:52 GMT 2005
Hi.
Jeroen . wrote:
> Sounds very plausable. But is also sounds like a big change.
No, not too much.
The PSAMP working group is going to specify a format for *exporting*
data, but they are not interested in the mechanism that has to be used
to configure the remote capture process.
From this point of view, rpcap is made up of two parts:
- the "configuration" protocol
- the "data export" protocol
Only the second one has to be changed.
In addition, due to some problem that we discovered later, also some
points in the "configuration" protocol have to be changed; however, this
sounds like a minor upgrade.
> In the mean time you need applications to start using the protocol so
> that you get
> the nesessary feedback. Any ideas how to overcome this dillema ?
>
> (I got some ideas of my own, about how i would go at it but this isn't
> the place for them I guess. I was looking for remote sniffer support and
> found this. Whenever there are two options, build-it-your-self or hook
> up with the standard, the choise is easy. Now you're saying the de facto
> standard for remote capturing is about to change and implementing the
> current is not a smart thing to do..)
Analyzer has remote sniffer support; as far as I know, also some
versions of Ethereal were able to capture packets remotely.
fulvio
>> From: Guy Harris <guy at alum.mit.edu>
>> To: winpcap-users at winpcap.org
>> CC: jeronimo8888 at hotmail.com
>> Subject: Re: [Winpcap-users] rpcap protocol
>> Date: Tue, 28 Jun 2005 09:28:47 -0700
>>
>> Fulvio Risso wrote:
>>
>>> We never put the documentation on the website because we do not
>>> believe this is the "last version" of the protocol.
>>> For isntance, we know some architectural bug that we plan to fix,
>>> sooner or later.
>>
>>
>> ...and there will probably be libpcap API changes that require
>> protocol changes, e.g. different calls for getting statistics (to
>> handle 64-bit counters and to get the statistics as a tag/value list,
>> so that new statistics can be added without breaking binary
>> compatibility and so that only the statistics supported by a given
>> platform are returned), a call to "set a filter" that takes a more
>> abstract representation of a filter expression (so that code can be
>> generated at the time the filter is set, to handle platforms that have
>> filter engines that don't support the BPF machine language, and to
>> handle reading capture files with multiple different link-layer
>> types), etc..
>>
>> In addition, there will probably be a fancier scheme of some sort for
>> doing authentication (would something such as SPNEGO make sense here,
>> so the client and server can negotiate what sort of authentication to
>> use?).
>>
>>> No, it is not.
>>> Unless the guy at sourceforge modified his protocol in order to be
>>> compatible with WinPcap.
>>
>>
>> Correct. His protocol was based on ONC RPC, but the one in WinPcap
>> isn't.
>
>
> _________________________________________________________________
> Talk with your online friends with MSN Messenger http://messenger.msn.nl/
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
More information about the Winpcap-users
mailing list