[Winpcap-users] RE: [tcpdump-workers] Support for win32 named pipes

[Gcom, Inc.]

This isn't sniffing named pipe communication, it's using a named pipe as a 
capture interface.

The end result is to allow ethereal (or other libpcap users) to read from a 
local win32 named pipe created by our application.  Basically, it's adding 
to win32 something that the Unix people have taken for granted:

mknod -p /tmp/my_fifo
my_application > /tmp/my_fifo &
ethereal -i /tmp/my_fifo &

It also avoids trying to open an interface like:  file://\\.\pipe\my_fifo

If we're going to add code to make more capture options available, we'd 
rather add them to libpcap/winpcap.

Regards,
Oolan Zimmer
Gcom, Inc.
ethereal at gcom.com

At 09:26 AM 6/29/2005, Alex Narinsky wrote:

>Can you please give additional explanation to your message?
>At present winpcap sniffs named pipes communication from MSSQL server
>client on another computer to a MSSQL server.  However, it does not
>catch local named pipes communications.
>
>What your development adds to these options?
>Thanks
>
>-----Original Message-----
>From: tcpdump-workers-owner at lists.tcpdump.org
>[mailto:tcpdump-workers-owner at lists.tcpdump.org] On Behalf Of Gcom, Inc.
>Sent: Tuesday, June 28, 2005 7:49 PM
>To: tcpdump-workers at lists.tcpdump.org
>Subject: [tcpdump-workers] Support for win32 named pipes
>
>I've added explicit support for named pipes to a winpcap 3.1 beta 4
>tree,
>and would like to submit the changes to the libpcap maintainers.  It
>adds a
>new file and small changes to several other files.  Who should I send
>diffs
>to, or should I send them to the list?  Would a modified source tree be
>easier to work with?
>
>The way the named pipe support I added works is, there is a new "family"
>of
>interface names, beginning with "pipe://".  On win32 machines, the name
>can
>have one of two formats:
>
>pipe://<pipename>
>pipe://<hostname>/<pipename>
>
>Win32 machines use a flat (non-hierarchical) namespace for the named
>pipes
>on each machine, and allow opening pipes on another machine.  The named
>pipe is assumed to carry a libpcap savefile-format data stream.
>
>On non-win32 machines, pipe://<path> is treated just like file://<path>
>
>The implementation adds a new API function pcap_open_pipe(), with the
>same
>parameters as pcap_open_live().
>
>The current implementation relies heavily on tweaked routines in
>savefile.c.  This is fine for an immediate implementation, but leaves
>out a
>few important distinctions between a savefile and a continuous data
>stream
>from a pipe.  This will be addressed in the future.
>
>Regards,
>Oolan Zimmer
>Gcom, Inc.
>ethereal at gcom.com
>
>-
>This is the tcpdump-workers list.
>Visit https://lists.sandelman.ca/ to unsubscribe.
>
>
>_______________________________________________
>Winpcap-users mailing list
>Winpcap-users at winpcap.org
>https://www.winpcap.org/mailman/listinfo/winpcap-users