Javier Acu�a wrote:
>I'm resending the patch to allow remote capturing. That is, to read data transmitted over TCP/IP. The sending side is the one responsible of capturing on some physical interface.
>
>
Hi Javier!
I had a look at your patch, and must say that IMHO it's not ready for
checkin for several reasons (no particular order):
- the GUI changes make the capture options dialog box even more
"unintuitive" than it already is (e.g. which "IP address" is meant).
However, I could fix this if the other problems are solved.
- 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
- command line: using two options '-d' and '-e' isn't a good idea, using
one with sub options might be a better idea (like the -a option)
- general concerns: you should follow the style of the original files
(indentation, curly brackets, ...)
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!!!
- As Guy Harris already asked, why not add this feature to libpcap?
- 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?)
- adding a remote capturing feature without providing the corresponding
server might be pretty useless
In general, this seems to be a "quick hack" to bring this feature to
life. There are some serious questions left open, which should be solved
first before doing further development.
Regards, ULFL