On 7/4/05, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> - I assume the changes won't work with Win32, e.g. the #include's in
> capture_loop.c will probably won't work on win32 and maybe not on "other
> unixes" as well
I would like to help here, but I never did serious network development
on Windows. Any volunteer? I could certainly work on the other two
minor issues.
> In general, most of the things mentioned above are minor points. The
> major problems are about the general functionality:
>
> - security: how do you avoid that someone else is capturing on the
> server you've provided? That's a serious security problem!!!
Yes, but at least my application is only used on a safe network
anyway, so I have no need for authentication. But I do understand that
other users have other environments.
My proposal to this problem would be to make Ethereal the server, and
the remote tracing tool the client. So intruders could still send
bogus data (note: they always can), but they can't intercept the data
any more. Also the configuration of Ethereal would be easier: only a
listening port number is necessary.
> - As Guy Harris already asked, why not add this feature to libpcap?
Hmhm. That sounds more difficult, but I can see the advantage.
> - did you noticed, that Winpcap already has a remote capturing feature,
> see: http://www.winpcap.org/docs/docs31beta4/html/group__remote.html (I
> don't know if the libpcap team is working on a similar feature, Guy?)
Yes, unfortunately the network interface is undocumented, so it would
be difficult (but very nice!) to come up with a compatible solution. I
will try to investigate this. Is winpcap still active? It seems like
they had some external disruptions, and no release since.
> - adding a remote capturing feature without providing the corresponding
> server might be pretty useless
A combination of tcpdump and nc should do the trick. This has to be
documented, but it is not a major stumbling block. Also winpcap has a
UNIX client, which might be interesting.
Thomas
