Javier Acu�a wrote:
>Hi, my answers below
>
>
>>Hi Javier!
>>
>>
>>- 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
>>
>>
>
>Hi, I'm a little confused.
>
>I know that pipes and sockets work in Unix, so Unix should be OK
>
>Regarding Windows, in the code to read from a pipe, it says that it won't work on Windows, but in gtk/main.c (a couple of lines above line 2000) you have an '#ifdef _WIN32' to allow reading from some pipe file descriptor.
>
>Since my 'hack' relies on reading from a pipe, I'm not sure if it's going to work in Windows.
>
>Anyhow, adding 'ifdef's' to make my code only visible to unix is a definite possibility.
>
>
There are two pipes involved:
- sync_pipe: control pipe from Ethereal capture child to parent,
transferring capture file names and such (on win32 there's another pipe
from parent to child as signals are not supported very well)
- capture_pipe (unix only): "real capture" from a named pipe (or '-'
stdin which is currently not working on some machines)
As you are reading from a socket (not a pipe), this should be possible
on win32 too. However, it might need some work to "tweak" things to
bring it to life.
>>- 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)
>>
>>
>
>OK.
>
>
This might also help to transfer username/password settings mentioned below.
>>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!!!
>>
>>
>
>I'm going to add username/password support now. I don't think sending the captured info encrypted is necessary,
>
>
>
I would think the same, what do others think. But please don't use plain
text authentication (as in FTP), this is as secure as doing it
completely without.
>
>
>>- As Guy Harris already asked, why not add this feature to libpcap?
>>
>>
>
>Because, as I already said, this is not for capturing. This is used to receive data from another program that does the capturing.
>
>
In the Ethereal sense, this *is* capturing. For Ethereal you'll start a
capture, no matter what it will do in the "real world". That's job of
libpcap/Winpcap.
>In our case, we use SS7 hardware, and we have stand alone drivers and applications that read data from those interfaces.
>
>This patchs opens the possibility of writing only the driver that interacts with some XXX new hardware, then sends the data to localhost:some_port and with Ethereal you have a new protocol analyzer on top of that new hardware.
>
>
Again, some other people will ask you why not use libpcap/Winpcap for
this purpose?
>>From what I gather, libpcap only reads from Ethernet devices. Adding this to libpcap limits us to Ethernet hardware.
>
>
No! libpcap supports several different hardware, see
http://www.ethereal.com/media.html which is all done by libpcap/Winpcap.
>Regarding WinPcap below,
>
>i) we don't use windows here.
>
>ii) the winpcap approach needs a server and a client. I'm only interested on embedding the client in Ethereal so It can receive from any given source.
>
>
The remote client is integrated into Winpcap. You'll also only need a
server rpcapd to work with this approach (which is available for unix
and win32).
>
>
>>- 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
>>
>>
>
>As I said, this is not bounded to any server. I'm sending a small server to test this patch
>
>
That's a good idea, so others will also benefit. As you don't put any
copyright notice in it, I assume that you meant to put this into the
public domain?
>>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.
>>
>>
>
>I didn't want to send a full fledged patch until I know you guys are intereted in adding this. Besides, by sending the previos quick hack I learned how to get the GUI thingie to work.
>
>
I understand, and think there are still some things left to think about.
Again, it would be better to integrate this into libpcap / Winpcap so
all programs (like tcpdump) can benefit from it and that's the place
where this feature really belongs to.
Regards, ULFL
