> On Fri, Jan 09, 2004 at 03:40:42PM -0600, Jeff Foster wrote:
>> 1) User authentication
>>
>> A flexible model including local (on server) authentication or
>> external authentication server.
>
> The RPCAP protocol, as far as I know, can support multiple
> authentication mechanisms; it currently supports "null" (no
> authentication) or user/password (I think both are sent in clear text)
> authentication. The authentication type is sent over the wire, along
> with the credentials.
>
> A GSSAPI-based authentication mechanism might be a useful addition.
>
>> 2) Data encryption
>>
>> The client/server communications must support encryption. In
>> addition non-encrypted traffic should be an option.
>
> Currently, RPCAP doesn't support that. It could probably be added.
>
>> 3) Client/Server Traffic
>>
>> The traffic should be kept to a minimum for usage over small
>> WAN connections. This should include filters based upon the
>> the current display filter options.
>
> Display filters are Ethereal-specific; RPCAP does support sending
> capture filters over the wire.
>
>> In addition the client should be able to request truncated
>> packets from server I.E. request the first 64 bytes from each
>> captured packet.
>
> You can specify a snapshot length in RPCAP.
I guess it would be best to help with the WinPcap rcapd instead of
re-inventing the wheel, since it works in linux. Hopefully add more
support as we have detailed, instead of it being a subset of winpcap,
possibly it can become more of its own feature set. Yet, I have still be
unable to get rcap working correctly in windows NT, or windows 2000. I
will bother their mailing list, haha.
--
Donnie
http://www.darthik.com
