[Ulf Lamping <ulf.lamping@xxxxxx>]

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