Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Thanks! On Wed, Nov 22, 2017 at 9:52 PM, James Ko wrote: > Done. https://code.wireshark.org/review/#/c/24536/ > > > Thanks, > > James > > > -- > *From:* Wireshark-dev on behalf of > Graham Bloice > *Sent:* Wednesday, November 22, 2017 10:22 > *To:* Developer support list for Wireshark > *Subject:* Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap > > > > On 22 November 2017 at 18:13, James Ko wrote: > > Attached is my patch to get this working (with caveats). > > To support this involved reading the the pcapng block header and parsing > the just the section header block for endianess. Then just rewrites the > all blocks using the original/input endianess format to the pipe without > looking much further at the block contents. > > It only supports one interface. I don't fully understand how multiple > interfaces are handled but would probably require parsing the interface > description blocks as well to get the linktype and snaplen to put in the > interface table. > > I also did not implement the use_threads option for packet processing. > > There is #ifdef WIN32 bits but I don't know if any of that is correct as I > didn't really touch it and did not even try to compile it. > > I hope this gets this feature moving along. > > Regards, > James > > > > > Please submit changes as per the Wiki page: https://wiki.wireshark. > org/Development/SubmittingPatches > > -- > Graham Bloice > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Done. https://code.wireshark.org/review/#/c/24536/ Thanks, James From: Wireshark-dev on behalf of Graham Bloice Sent: Wednesday, November 22, 2017 10:22 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap On 22 November 2017 at 18:13, James Ko mailto:jim.l...@hotmail.com>> wrote: Attached is my patch to get this working (with caveats). To support this involved reading the the pcapng block header and parsing the just the section header block for endianess. Then just rewrites the all blocks using the original/input endianess format to the pipe without looking much further at the block contents. It only supports one interface. I don't fully understand how multiple interfaces are handled but would probably require parsing the interface description blocks as well to get the linktype and snaplen to put in the interface table. I also did not implement the use_threads option for packet processing. There is #ifdef WIN32 bits but I don't know if any of that is correct as I didn't really touch it and did not even try to compile it. I hope this gets this feature moving along. Regards, James Please submit changes as per the Wiki page: https://wiki.wireshark.org/Development/SubmittingPatches -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On 22 November 2017 at 18:13, James Ko wrote: > Attached is my patch to get this working (with caveats). > > To support this involved reading the the pcapng block header and parsing > the just the section header block for endianess. Then just rewrites the > all blocks using the original/input endianess format to the pipe without > looking much further at the block contents. > > It only supports one interface. I don't fully understand how multiple > interfaces are handled but would probably require parsing the interface > description blocks as well to get the linktype and snaplen to put in the > interface table. > > I also did not implement the use_threads option for packet processing. > > There is #ifdef WIN32 bits but I don't know if any of that is correct as I > didn't really touch it and did not even try to compile it. > > I hope this gets this feature moving along. > > Regards, > James > > > > Please submit changes as per the Wiki page: https://wiki.wireshark.org/Development/SubmittingPatches -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Sorry, that was meant to be gerrit. See https://code.wireshark.org/review/ cheers On Wed, Nov 22, 2017 at 7:19 PM, Roland Knall wrote: > Hi > > Could you send this to gerri for review? It makes it a lot easier to > integrate into master > > cheers > Roland > > On Wed, Nov 22, 2017 at 7:13 PM, James Ko wrote: > >> Attached is my patch to get this working (with caveats). >> >> To support this involved reading the the pcapng block header and parsing >> the just the section header block for endianess. Then just rewrites the >> all blocks using the original/input endianess format to the pipe without >> looking much further at the block contents. >> >> It only supports one interface. I don't fully understand how multiple >> interfaces are handled but would probably require parsing the interface >> description blocks as well to get the linktype and snaplen to put in the >> interface table. >> >> I also did not implement the use_threads option for packet processing. >> >> There is #ifdef WIN32 bits but I don't know if any of that is correct as >> I didn't really touch it and did not even try to compile it. >> >> I hope this gets this feature moving along. >> >> Regards, >> James >> >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscr >> ibe >> > > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Hi Could you send this to gerri for review? It makes it a lot easier to integrate into master cheers Roland On Wed, Nov 22, 2017 at 7:13 PM, James Ko wrote: > Attached is my patch to get this working (with caveats). > > To support this involved reading the the pcapng block header and parsing > the just the section header block for endianess. Then just rewrites the > all blocks using the original/input endianess format to the pipe without > looking much further at the block contents. > > It only supports one interface. I don't fully understand how multiple > interfaces are handled but would probably require parsing the interface > description blocks as well to get the linktype and snaplen to put in the > interface table. > > I also did not implement the use_threads option for packet processing. > > There is #ifdef WIN32 bits but I don't know if any of that is correct as I > didn't really touch it and did not even try to compile it. > > I hope this gets this feature moving along. > > Regards, > James > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject= > unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Attached is my patch to get this working (with caveats).
To support this involved reading the the pcapng block header and parsing the
just the section header block for endianess. Then just rewrites the all blocks
using the original/input endianess format to the pipe without looking much
further at the block contents.
It only supports one interface. I don't fully understand how multiple
interfaces are handled but would probably require parsing the interface
description blocks as well to get the linktype and snaplen to put in the
interface table.
I also did not implement the use_threads option for packet processing.
There is #ifdef WIN32 bits but I don't know if any of that is correct as I
didn't really touch it and did not even try to compile it.
I hope this gets this feature moving along.
Regards,
James
diff --git a/dumpcap.c b/dumpcap.c
index cc420ba..6fff51f 100644
--- a/dumpcap.c
+++ b/dumpcap.c
@@ -108,6 +108,7 @@
*/
#include "wiretap/libpcap.h"
#include "wiretap/pcapng_module.h"
+#include "wiretap/pcapng.h"
/**#define DEBUG_DUMPCAP**/
/**#define DEBUG_CHILD_DUMPCAP**/
@@ -270,8 +271,15 @@ typedef struct _capture_src {
/**< capture pipe (unix only "input file") */
gboolean from_cap_pipe; /**< TRUE if we are capturing data from a capture pipe */
gboolean from_cap_socket;/**< TRUE if we're capturing from socket */
-struct pcap_hdr cap_pipe_hdr; /**< Pcap header when capturing from a pipe */
-struct pcaprec_modified_hdr cap_pipe_rechdr;/**< Pcap record header when capturing from a pipe */
+gboolean from_pcapng;/**< TRUE if we're capturing from pcapng format */
+union {
+struct pcap_hdr cap_pipe_hdr; /**< Pcap header when capturing from a pipe */
+struct pcapng_section_header_block_s pcapng_pipe_shb; /**< Pcapng header when capturing from a pipe */
+};
+union {
+struct pcaprec_modified_hdr cap_pipe_rechdr;/**< Pcap record header when capturing from a pipe */
+struct pcapng_block_header_s pcapng_pipe_bh; /**< Pcapng block header when capturing from a pipe */
+};
#ifdef _WIN32
HANDLE cap_pipe_h; /**< The handle of the capture pipe */
#endif
@@ -388,6 +396,8 @@ static void capture_loop_write_packet_cb(u_char *pcap_src_p, const struct pcap_p
const u_char *pd);
static void capture_loop_queue_packet_cb(u_char *pcap_src_p, const struct pcap_pkthdr *phdr,
const u_char *pd);
+static void capture_loop_write_pcapng_shb(u_char *pcap_src_p, const u_char *pd);
+static void capture_loop_write_pcapng_block(u_char *pcap_src_p, const u_char *pd);
static void capture_loop_get_errmsg(char *errmsg, int errmsglen, const char *fname,
int err, gboolean is_close);
@@ -1452,6 +1462,10 @@ cap_pipe_close(int pipe_fd, gboolean from_socket _U_)
#endif
}
+/* Some forward declarations for breaking up cap_pipe_open_live for pcap and pcapng formats */
+static void pcap_pipe_open_live(int fd, capture_src *pcap_src, struct pcap_hdr *hdr, char *errmsg, int errmsgl);
+static void pcapng_pipe_open_live(int fd, capture_src *pcap_src, struct pcapng_section_header_block_s *hdr, char *errmsg, int errmsgl);
+
/* Mimic pcap_open_live() for pipe captures
* We check if "pipename" is "-" (stdin), a AF_UNIX socket, or a FIFO,
@@ -1462,7 +1476,7 @@ cap_pipe_close(int pipe_fd, gboolean from_socket _U_)
static void
cap_pipe_open_live(char *pipename,
capture_src *pcap_src,
- struct pcap_hdr *hdr,
+ void *hdr,
char *errmsg, int errmsgl)
{
#ifndef _WIN32
@@ -1774,16 +1788,38 @@ cap_pipe_open_live(char *pipename,
pcap_src->cap_pipe_modified = TRUE;
break;
case BLOCK_TYPE_SHB:
-/* This isn't pcap, it's pcapng. We don't yet support
- reading it. */
-g_snprintf(errmsg, errmsgl, "Capturing from a pipe doesn't support pcapng format.");
-goto error;
+pcap_src->pcapng_pipe_bh.block_type = BLOCK_TYPE_SHB;
+pcap_src->from_pcapng = TRUE;
+global_capture_opts.use_pcapng = TRUE;
+pcapng_pipe_open_live(fd, pcap_src, (struct pcapng_section_header_block_s *) hdr, errmsg, errmsgl);
+return;
default:
/* Not a pcap type we know about, or not pcap at all. */
g_snprintf(errmsg, errmsgl, "Unrecognized libpcap format or not libpcap data.");
goto error;
}
+pcap_pipe_open_live(fd, pcap_src, (struct pcap_hdr *) hdr, errmsg, errmsgl);
+return;
+error:
+g_log(LOG_DOMAIN_CAPTURE_CHILD, G_LOG_LEVEL_DEBUG, "cap_pipe_open_live: error %s", errmsg);
+pcap_src->cap_pipe_err = PIPERR;
+cap_pipe_
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 31, 2017, at 10:13 PM, Anthony Coddington wrote: > Wtap filetypes could indicate that they do/do not support sequential only > access with a flag in dump_open_table. There is already a flag for > writing_must_seek. I'm sure at some point I saw some support in wtap > internals for trying to read from pipes/stdin without random seeking support? Libwiretap, in principle, requires seeking, because it determines the file type by, for all file types, attempting to read the file as if it were a file of that type until it either finds a file type that claims the file, gets an I/O error, or runs out of file types. It does this by, for each file type, seeking back to the beginning of the file and calling the "open" routine. In practice, the low-level code for reading from files has a buffer and implements seeking within the buffer by just adjusting an internal pointer, so *if* the first buffer read contains sufficient data, for all file types, to either identify the file as being of that type or not being of that type, we can determine the file type without actually adjusting the file descriptor's seek position, allowing it to work when reading from a pipe. For files with a magic number at the beginning, that could work, as the buffer size is 4K (unless the OS supports the st_blksize member of the stat structure, and, for a given file/file system, the returned "recommended" block size isn't 4K, e.g. 8K on an 8K/1K BSD FFS file system), and for most (if not all) files with magic numbers, the magic number is within the first 4K bytes of the file, so the test just keep reading out of the buffer. That would require, however, either that: 1) if the wiretap/file_wrappers.c code reads into the buffer, and doesn't get a full 4K, subsequent reads append to the buffer until it fills, rather than having the code process what's in the buffer and then do the next read starting at the beginning of the buffer or 2) anything writing to a pipe is guaranteed to, in the first write, write enough data for all magic numbers, and all OSes buffer that full amount, so that the first read gets enough data for all magic numbers. For file formats unfortunate enough not to have a magic number, the open routine has to be able to say "this is my file" or "this is not my file" given only the first 4K bytes of data - or we need to increase the "guaranteed minimum unless the file itself is smaller" value to something big enough for all file types. > If necessary wtap could be extended to have wtap filetypes return a 'need > more data' rather than WTAP_ERR_SHORT_READ or blocking if they don't have the > rest of the packet but have not reached EOF. If there's currently any place in libwiretap where we return WTAP_ERR_SHORT_READ if we haven't finished reading a record but we haven't reached EOF, rather than just reading until we *do* finish reading the record, that's a colossal bug and needs to be fixed immediately. We *could*, I guess, provide a "non-blocking" mode, wherein if an attempt to read from a file returns EAGAIN before we're finished reading a record, we return an equivalent "trying to read more stuff would block" error, but: 1) that change would go all the way down into the middle of wiretap/file_wrappers.c, and would probably complicate that code path significantly; 2) once that's done, other code paths also get more complicated (look at the stuff that reads from files vs. the stuff that captures from pipes!); so it may be that if we want to be able to capture from a pipe, and not block the UI when waiting for input from the pipe, a simpler solution might be to stuff the "capture from a pipe" stuff into a separate thread that just does ordinary blocking reads from the pipe. (Back when Wireshark^WEthereal was originally written, threading wasn't supported by many of the platforms on which it ran. Now, we use threading in dumpcap and the GTK+ UI, with the GLib g_thread_ routines.) > There is also nothing stopping having an interface for extcap that requires > dumping to an intermediate file for files that require seeking. At least one file type that requires seeking is NetMon files, and you can't read them until you've written the entire file, so you just couldn't use it for extcap. But I'm not sure there's any good reason to do so. Another is the NetXRay/Windows Sniffer format, where the file's contents are probably an in-memory ring buffer dumped to the file, so you start reading in the middle of the file and, when you hit the end of the file, you wrap around. But I'm not sure there's a good reason to use that format, either. There are cases where we seek forward, but we can implement that, on a sequential stream, by just reading data and throwing it away, using file_read() with a null pointer to the buffer into which to read data. ___ Sent via:Wiresh
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Thu, Aug 31, 2017 at 2:32 PM, Guy Harris wrote: > On Aug 31, 2017, at 11:09 AM, Jeff Morriss > wrote: > > > A counter argument to this would be that there are some advantages to > not using a (temporary) file as the buffer packets. > > For Wireshark, you have no alternative, as packets aren't processed only > once. > > For TShark with -2, the same applies. > > TShark with one pass is the one place where you wouldn't want a temporary > file. > Ah, I guess implicit in my statement was the thought that we'd (have to) go back to *shark writing the file. Which would mean that while it could solve the 2 bugs it wouldn't do anything about the fact that the data's going to a file (except that it would allow the user to limit how much data is going to the file with a read filter). (So my 3rd point is somewhat meaningless.) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 31, 2017, at 1:31 PM, Guy Harris wrote: > On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: > > There are some limitations. Specifically, pipes don't allow random access, >so any file formats that currently require that would need to either be >rewritten > Which, for at least one capture file format (Network Monitor format), would >be impossible, as we don't define it, Microsoft does (and they're probably not >very amenable to changing it, not least because they've deprecated NetMon in >favor of Message Analyzer). The only file formats *we* control to any degree >are pcap and pcapng, neither of which require random access in order to read >them sequentially. > If we make extcap programs work like dumpcap, the only pipe involved is the >control pipe between *shark and the program - the packets are written directly >to a file - but that wouldn't make any difference for those file formats, as >you can't, for example, read a NetMon file until it's *completely* written, >with a frame table, and you can't do that until you've written all the packets >to it. Wtap filetypes could indicate that they do/do not support sequential only access with a flag in dump_open_table. There is already a flag for writing_must_seek. I'm sure at some point I saw some support in wtap internals for trying to read from pipes/stdin without random seeking support? If necessary wtap could be extended to have wtap filetypes return a 'need more data' rather than WTAP_ERR_SHORT_READ or blocking if they don't have the rest of the packet but have not reached EOF. There is also nothing stopping having an interface for extcap that requires dumping to an intermediate file for files that require seeking. Also note that with the extcap toolbar support there is now optionally already a control pipe to and from extcap applications. One option would be to extend and use that interface to indicate when packets are available. In dumpcap as well ideally (replacing the capchild control pipe). Not sure if it is feasible to suggest extcap applications flush the output pipe only on packet boundaries? Regards, Anthony From: Wireshark-dev on behalf of Guy Harris Sent: Thursday, 31 August 2017 1:31 p.m. To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: > One problem is that as dumpcap is currently written, it treats files and > pipes very differently. *Files* and pipes, or *capture devices* and pipes? > but I can't help but think that the general approach you describe is the > better long term strategy. Probably. It means that the interface between *shark and extcap programs would be different - but, while having extcap programs behave like dumpcap might complicate the extcap programs (although some of the code to do that could be in a library used by dumpcap and by extcap programs), it might simplify the Wireshark capture code path. > There are some limitations. Specifically, pipes don't allow random access, > so any file formats that currently require that would need to either be > rewritten Which, for at least one capture file format (Network Monitor format), would be impossible, as we don't define it, Microsoft does (and they're probably not very amenable to changing it, not least because they've deprecated NetMon in favor of Message Analyzer). The only file formats *we* control to any degree are pcap and pcapng, neither of which require random access in order to read them sequentially. If we make extcap programs work like dumpcap, the only pipe involved is the control pipe between *shark and the program - the packets are written directly to a file - but that wouldn't make any difference for those file formats, as you can't, for example, read a NetMon file until it's *completely* written, with a frame table, and you can't do that until you've written all the packets to it. However, I suspect Stephen is thinking of ERF format, which should be writable purely sequentially, so it shouldn't be a problem, whether you're writing to a pipe or to a file that's being read incrementally. ___ Sent via: Wireshark-dev mailing list Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 31, 2017, at 11:09 AM, Jeff Morriss wrote: > A counter argument to this would be that there are some advantages to not > using a (temporary) file as the buffer packets. For Wireshark, you have no alternative, as packets aren't processed only once. For TShark with -2, the same applies. TShark with one pass is the one place where you wouldn't want a temporary file. And the current scheme we have for extcap involves a temporary file, as the extcap programs talk to dumpcap, which always writes temporary files. So, if we want to get rid of the temporary file for one-pass TShark (which would probably be a good idea), what we'd want to do is have extcap piping packets directly to TShark. If we can also have TShark directly capturing (with a libpcap that does its own privilege separation), completely removing dumpcap: one-pass TShark would read packets from a pcap_t or a pipe, writing to a file *if* asked to do so, and dissecting packets *if* asked to do so; two-pass TShark would read packets from a pcap_t or a pipe, writing to a file unconditionally, dissecting the packets but not printing anything and, when the capture is complete, going back and re-dissecting the packets in the file and printing the results. Wireshark would, in this world, read packets from a pcap_t or a pipe, writing to a file unconditionally, and adding them to its packet list, but not displaying the results of that dissection (not generating columns or a protocol tree); the packet list and packet details panes would display stuff based on a subsequent dissection (so it shows the result of dissections *after* the first pass). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Thu, Aug 31, 2017 at 12:54 PM, Guy Harris wrote: > On Aug 31, 2017, at 3:37 AM, Ed Beroset wrote: > > > On 08/30/2017 09:31 PM, Guy Harris wrote: > >> On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: > >>> but I can't help but think that the general approach you describe is > the better long term strategy. > >> Probably. It means that the interface between *shark and extcap > programs would be different - but, while having extcap programs behave like > dumpcap might complicate the extcap programs (although some of the code to > do that could be in a library used by dumpcap and by extcap programs), it > might simplify the Wireshark capture code path. > > > > I'm not sure that the interface between dumpcap and Wireshark/tshark > would need to change to accommodate a wider variety of inputs via pipes. > > It wouldn't. > > The interface between *extcap programs* and Wireshark/tshark would need to > change if we want to have extcap programs work like dumpcap, so that they > talk directly to Wireshark/tshark, and write directly to a capture file, > rather than talking to dumpcap by sending packets over a pipe. That was > Stephen's suggestion, and I think it's worth considering. > A counter argument to this would be that there are some advantages to not using a (temporary) file as the buffer packets. The ones I've had in mind for some time are: * Bug 2234 (filtering tshark captures with read filters (-R) no longer works) - an Known Problem in our release notes since privsep came in. * Bug 1650 (dumpcap can remove a ring-buffer file before *shark has read it; the resulting packet loss is reasonable but error presented to the user is quite bad). * Just the general idea of using (slow) files for a buffer. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 31, 2017, at 3:37 AM, Ed Beroset wrote: > On 08/30/2017 09:31 PM, Guy Harris wrote: >> On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: >>> One problem is that as dumpcap is currently written, it treats files and >>> pipes very differently. >> *Files* and pipes, or *capture devices* and pipes? > > Actually, I meant to say pipes and sockets. That's because 1) UN*Xes tend to support select()/poll()/epoll()/kqueues/etc. on just about all descriptors while 2) Windows doesn't support the WaitFor APIs on all handles, and pipes are different from sockets. >>> but I can't help but think that the general approach you describe is the >>> better long term strategy. >> Probably. It means that the interface between *shark and extcap programs >> would be different - but, while having extcap programs behave like dumpcap >> might complicate the extcap programs (although some of the code to do that >> could be in a library used by dumpcap and by extcap programs), it might >> simplify the Wireshark capture code path. > > I'm not sure that the interface between dumpcap and Wireshark/tshark would > need to change to accommodate a wider variety of inputs via pipes. It wouldn't. The interface between *extcap programs* and Wireshark/tshark would need to change if we want to have extcap programs work like dumpcap, so that they talk directly to Wireshark/tshark, and write directly to a capture file, rather than talking to dumpcap by sending packets over a pipe. That was Stephen's suggestion, and I think it's worth considering. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
I apologize for dropping off the map on this. My employers decided that other projects were of higher priority this summer, and this fell by the wayside. The other projects have reached completion, and I am still very interested in implementing this functionality, and so is my employer. I have a partner, Ben (bandrew...@winona.edu) who is also working on implementing this with me. We are willing to put in the time and effort required, but we also do not want to be an obstruction to this getting done. I know I had a couple of false starts, so if its time to give it to someone else, I understand. Richard, thank you for your patience and willingness to reach out personally. If it still makes sense for us to work on this, we will strive to implement this feature quickly while keeping you and Ed up to date on our progress. --Evan From: Wireshark-dev on behalf of Richard Sharpe Sent: Wednesday, August 30, 2017 8:23:35 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap On Wed, Aug 30, 2017 at 1:21 AM, Anders Broman wrote: > > > -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of > Ed Beroset > Sent: den 29 augusti 2017 21:40 > To: wireshark-dev@wireshark.org > Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap > > On 08/29/2017 02:35 PM, Richard Sharpe wrote: >>> On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset wrote: >>>> On 06/16/2017 01:27 PM, Richard Sharpe wrote: >>>> >>>> I've just encountered a need for this as well. Have you made >>>> progress, Evan? Do you want some help? >>> >>> Evan seems to have dropped off the radar. I outlined to Evan an >>> approach for doing this, so I could send it to Ed instead ... >> >>It would be helpful if you could. I've looked at your old patch and I've >>been looking over the dumpcap.c code and have been making some notes, but it >>would nice to have >additional input on this, especially since you've already >>looked at it. Thanks! FWIW, here are the notes I sent Evan and Ed: --- > The patch that I pointed you at is incomplete because it does not > handle PCAPNG captures being piped at you. In addition I am no longer > happy with exposing the internals of the struct capture_src like that. > > It should be easy to add pcapng support by detecting in > cap_pipe_open_live that you are dealing with PCAPNG rather than PCAP, > since you will see that you have an PCAPNG capture because the Section > Header Block magic (block type) is 32 bits and is different than any > of the PCAP magic values, and there must be at least one SHB in a > PCAPNG capture. > > Thus you can use that to choose which state machine should be used for > the subsequent reads. > > I think it might be cleaner to extract the current PCAP state machine > into its own function and create a new one for PCAPNG ... and I will > have more thoughts later after I have thought about this some more. More thoughts ... 1. Rename cap_pipe_dispatch to pcap_pipe_dispatch. 2. Create a new pcapng_pipe_dispatch. It only has to deal with two record types. SHBs and all others. The reason you have to deal with SHBs specially is that they can change the endianness of the capture until you see the next SHB. Each block, including the SHB has a length field as the second 32-bit field and the last 32-bit field. The SHB's length cannot be interpreted until you figure out the endianness which is determined from the third 32-bit field. It also contains a total length for the section. 3. The first SHB has to be dealt with specially since you need to read the first 32-bits (the MAGIC) to figure out whether or not you are dealing with PCAP or PCAPNG. After that, SHBs still need to be dealt with specially, but other blocks are simple to deal with. Read the first 8 bytes, and if the MAGIC says it is not an SHB, the second 4-byte field tells you how many more bytes to read. Then you can simply write the lot out. For each non-first SHB, you need to read another 4 bytes to figure out the endianness field (4-bytes) to determine how to interpret the second field. 4. Modify pcap_dispatch to call pcap_pipe_dispatch or pcapng_pipe_dispatch depending on the the type of the capture determined from reading the very first MAGIC field. 5. cap_pipe_dispatch may look complex because of all those #ifdef's but that is simply to support Windows as well as Linux. It should be possible to create pcapng_pipe_dispatch along similar lines as well. There is probably only two states, or maybe three states, for pcapng_pipe_dispatch: PCAPNG_STATE_EX
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On 08/30/2017 09:31 PM, Guy Harris wrote: On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: One problem is that as dumpcap is currently written, it treats files and pipes very differently. *Files* and pipes, or *capture devices* and pipes? Actually, I meant to say pipes and sockets. but I can't help but think that the general approach you describe is the better long term strategy. Probably. It means that the interface between *shark and extcap programs would be different - but, while having extcap programs behave like dumpcap might complicate the extcap programs (although some of the code to do that could be in a library used by dumpcap and by extcap programs), it might simplify the Wireshark capture code path. I'm not sure that the interface between dumpcap and Wireshark/tshark would need to change to accommodate a wider variety of inputs via pipes. What I meant was that much of the parsing and interpretation of the file formats seems to be essentially the same whether the data arrives as a file or as data in a pipe, so it seems, perhaps naively, that some of the code could also be shared. There are some limitations. Specifically, pipes don't allow random access, so any file formats that currently require that would need to either be rewritten Which, for at least one capture file format (Network Monitor format), would be impossible, as we don't define it, Microsoft does (and they're probably not very amenable to changing it, not least because they've deprecated NetMon in favor of Message Analyzer). The only file formats *we* control to any degree are pcap and pcapng, neither of which require random access in order to read them sequentially. Partly for that reason, I've been concentrating my efforts on only those two formats for pipe input. My patch is still quite rough, but it's working for my purposes. Ed ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
From: Guy Harris on Thursday, 31 August 2017 1:24 PM
> On Aug 30, 2017, at 4:58 PM, Stephen Donnelly
> wrote:
>> At the very least extcap tools should be able to supply data in any format
>> understood by wiretap, but since the extcap data currently goes via dumpcap
>> (maybe not sensible either?)
>
> Perhaps not, indeed.
>
> Currently, there's a protocol between dumpcap and {Wireshark,TShark} allowing
> dumpcap to tell *shark "I've appended N more packets to the capture file", to
> allow dumpcap to report errors and "here's another capture file" (if it's
> doing multiple files), etc..
>
> If extcap programs were to speak that protocol when capturing, you could have
> the extcap programs behave similarly to dumpcap, writing packets directly to
> a file, and have *shark run the extcap program rather than running dumpcap.
> I.e., make extcap programs act as substitutes for dumpcap.
Agreed. In fact if extcap programs can talk directly to *shark, then dumpcap
becomes just another extcap program and not especially privileged.
Stephen
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 30, 2017, at 6:00 PM, Ed Beroset wrote: > One problem is that as dumpcap is currently written, it treats files and > pipes very differently. *Files* and pipes, or *capture devices* and pipes? > but I can't help but think that the general approach you describe is the > better long term strategy. Probably. It means that the interface between *shark and extcap programs would be different - but, while having extcap programs behave like dumpcap might complicate the extcap programs (although some of the code to do that could be in a library used by dumpcap and by extcap programs), it might simplify the Wireshark capture code path. > There are some limitations. Specifically, pipes don't allow random access, > so any file formats that currently require that would need to either be > rewritten Which, for at least one capture file format (Network Monitor format), would be impossible, as we don't define it, Microsoft does (and they're probably not very amenable to changing it, not least because they've deprecated NetMon in favor of Message Analyzer). The only file formats *we* control to any degree are pcap and pcapng, neither of which require random access in order to read them sequentially. If we make extcap programs work like dumpcap, the only pipe involved is the control pipe between *shark and the program - the packets are written directly to a file - but that wouldn't make any difference for those file formats, as you can't, for example, read a NetMon file until it's *completely* written, with a frame table, and you can't do that until you've written all the packets to it. However, I suspect Stephen is thinking of ERF format, which should be writable purely sequentially, so it shouldn't be a problem, whether you're writing to a pipe or to a file that's being read incrementally. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Aug 30, 2017, at 4:58 PM, Stephen Donnelly
wrote:
> At the very least extcap tools should be able to supply data in any format
> understood by wiretap, but since the extcap data currently goes via dumpcap
> (maybe not sensible either?)
Perhaps not, indeed.
Currently, there's a protocol between dumpcap and {Wireshark,TShark} allowing
dumpcap to tell *shark "I've appended N more packets to the capture file", to
allow dumpcap to report errors and "here's another capture file" (if it's doing
multiple files), etc..
If extcap programs were to speak that protocol when capturing, you could have
the extcap programs behave similarly to dumpcap, writing packets directly to a
file, and have *shark run the extcap program rather than running dumpcap.
I.e., make extcap programs act as substitutes for dumpcap.
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On 08/30/2017 07:58 PM, Stephen Donnelly wrote: Why pcap-ng specifically? Although pcap-ng is higher featured than pcap, it is not Wireshark's internal representation. Pcap-ng is merely the default output format. I don't know about other people's desire for this, but here's mine: I am working on a Raspberry Pi based sniffer tool for IEEE 802.15.4 traffic and want to be able to have the Pi serve up sniffed packets to an instance of Wireshark on another machine. Rather than fiddle with pcap, it seemed to make sense to me to use pcapng as the output format for the Pi-based sniffer. It was only after I had finished that, that I realized that pcapng was not supported via a pipe. Since Wireshark has the ability to detect and read multiple formats already in wiretap, why not leverage that? At the very least extcap tools should be able to supply data in any format understood by wiretap, but since the extcap data currently goes via dumpcap (maybe not sensible either?) they are restricted to pcap only and have to convert to that internally, potentially losing information. Yes, exactly the situation. So I've created a patch which works for my immediate needs, but is rather hack-ish and ugly for any other, at least in part due to some of the factors you mention. Wouldn’t it be better for the capture tool to indicate which of the wiretap formats it intends to use, rather than switching from one fixed format to a different fixed format? This would then support both pcap and pcap-ng intrinsically, as well as all other formats. One problem is that as dumpcap is currently written, it treats files and pipes very differently. Part of that appears to be due to the fact that Windows treats them very differently, but I can't help but think that the general approach you describe is the better long term strategy. There are some limitations. Specifically, pipes don't allow random access, so any file formats that currently require that would need to either be rewritten or omitted for the pipe-able formats. Might be doable in that way, but it would require a lot of re-engineering. Ed ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
> Richard Sharpe Sent: Saturday, 17 June 2017 5:28 AM > > > On Fri, Jun 16, 2017 at 9:36 AM, Kvidera, Evan D > > wrote: > > Hello Wireshark Devs, > > > > My name is Evan Kvidera and I am a senior undergraduate student > > studying Computer Science. I have a decent amount of programming > > experience, but only a little in C. My employer has asked me to try to > > add support for piping pcap-ng captures to Wireshark. > > I have read over the bug report requesting the feature, > > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370. > > > > After reading the mailing list archives here, > > https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html > > , it looks like this addition will be nontrivial, but doable, and that > > the changes necessary are all going to be in dumpcap. > > > > I have at least a month or two of full-time work I can dedicate to > > this if necessary, although I am hoping it will not take that long. > > > > I have read through the Wireshark Developer's Guide and looked over > > the style guide for Wireshark. Is there anything else I should know > > before starting development? I will try to develop this as > > independently as possible, but I may have a few questions along the way. > > Hi Evan, > > I looked at this back in 2012 and even proposed a patch that might be useful > to you: > > http://seclists.org/wireshark/2012/May/25 > > No doubt it was a little too simplistic but if I find some time next week > while I am in Seattle I might try to resurrect it and see if it works. Why pcap-ng specifically? Although pcap-ng is higher featured than pcap, it is not Wireshark's internal representation. Pcap-ng is merely the default output format. Since Wireshark has the ability to detect and read multiple formats already in wiretap, why not leverage that? At the very least extcap tools should be able to supply data in any format understood by wiretap, but since the extcap data currently goes via dumpcap (maybe not sensible either?) they are restricted to pcap only and have to convert to that internally, potentially losing information. Wouldn’t it be better for the capture tool to indicate which of the wiretap formats it intends to use, rather than switching from one fixed format to a different fixed format? This would then support both pcap and pcap-ng intrinsically, as well as all other formats. Regards, Stephen ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Wed, Aug 30, 2017 at 1:21 AM, Anders Broman wrote: > > > -Original Message- > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of > Ed Beroset > Sent: den 29 augusti 2017 21:40 > To: wireshark-dev@wireshark.org > Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap > > On 08/29/2017 02:35 PM, Richard Sharpe wrote: >>> On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset wrote: >>>> On 06/16/2017 01:27 PM, Richard Sharpe wrote: >>>> >>>> I've just encountered a need for this as well. Have you made >>>> progress, Evan? Do you want some help? >>> >>> Evan seems to have dropped off the radar. I outlined to Evan an >>> approach for doing this, so I could send it to Ed instead ... >> >>It would be helpful if you could. I've looked at your old patch and I've >>been looking over the dumpcap.c code and have been making some notes, but it >>would nice to have >additional input on this, especially since you've already >>looked at it. Thanks! FWIW, here are the notes I sent Evan and Ed: --- > The patch that I pointed you at is incomplete because it does not > handle PCAPNG captures being piped at you. In addition I am no longer > happy with exposing the internals of the struct capture_src like that. > > It should be easy to add pcapng support by detecting in > cap_pipe_open_live that you are dealing with PCAPNG rather than PCAP, > since you will see that you have an PCAPNG capture because the Section > Header Block magic (block type) is 32 bits and is different than any > of the PCAP magic values, and there must be at least one SHB in a > PCAPNG capture. > > Thus you can use that to choose which state machine should be used for > the subsequent reads. > > I think it might be cleaner to extract the current PCAP state machine > into its own function and create a new one for PCAPNG ... and I will > have more thoughts later after I have thought about this some more. More thoughts ... 1. Rename cap_pipe_dispatch to pcap_pipe_dispatch. 2. Create a new pcapng_pipe_dispatch. It only has to deal with two record types. SHBs and all others. The reason you have to deal with SHBs specially is that they can change the endianness of the capture until you see the next SHB. Each block, including the SHB has a length field as the second 32-bit field and the last 32-bit field. The SHB's length cannot be interpreted until you figure out the endianness which is determined from the third 32-bit field. It also contains a total length for the section. 3. The first SHB has to be dealt with specially since you need to read the first 32-bits (the MAGIC) to figure out whether or not you are dealing with PCAP or PCAPNG. After that, SHBs still need to be dealt with specially, but other blocks are simple to deal with. Read the first 8 bytes, and if the MAGIC says it is not an SHB, the second 4-byte field tells you how many more bytes to read. Then you can simply write the lot out. For each non-first SHB, you need to read another 4 bytes to figure out the endianness field (4-bytes) to determine how to interpret the second field. 4. Modify pcap_dispatch to call pcap_pipe_dispatch or pcapng_pipe_dispatch depending on the the type of the capture determined from reading the very first MAGIC field. 5. cap_pipe_dispatch may look complex because of all those #ifdef's but that is simply to support Windows as well as Linux. It should be possible to create pcapng_pipe_dispatch along similar lines as well. There is probably only two states, or maybe three states, for pcapng_pipe_dispatch: PCAPNG_STATE_EXPECT_PREAMBLE (for the first 8 bytes), PCAPNG_NG_STATE_READ_DATA for the remaining data in the record, and PCAPNG_STATE_EXPECT_SHB_ENDIAN for the 4-byte endianness indicator of an SHB. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
-Original Message- From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Ed Beroset Sent: den 29 augusti 2017 21:40 To: wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap On 08/29/2017 02:35 PM, Richard Sharpe wrote: >> On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset wrote: >>> On 06/16/2017 01:27 PM, Richard Sharpe wrote: >>> >>> I've just encountered a need for this as well. Have you made >>> progress, Evan? Do you want some help? >> >> Evan seems to have dropped off the radar. I outlined to Evan an >> approach for doing this, so I could send it to Ed instead ... > >It would be helpful if you could. I've looked at your old patch and I've been >looking over the dumpcap.c code and have been making some notes, but it would >nice to have >additional input on this, especially since you've already looked >at it. Thanks! > >Ed Please send the notes to the list it may be useful for future reference. Regards Anders ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On 08/29/2017 02:35 PM, Richard Sharpe wrote: On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset wrote: On 06/16/2017 01:27 PM, Richard Sharpe wrote: I've just encountered a need for this as well. Have you made progress, Evan? Do you want some help? Evan seems to have dropped off the radar. I outlined to Evan an approach for doing this, so I could send it to Ed instead ... It would be helpful if you could. I've looked at your old patch and I've been looking over the dumpcap.c code and have been making some notes, but it would nice to have additional input on this, especially since you've already looked at it. Thanks! Ed ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Tue, Aug 29, 2017 at 10:50 AM, Ed Beroset wrote: > On 06/16/2017 01:27 PM, Richard Sharpe wrote: >> >> On Fri, Jun 16, 2017 at 9:36 AM, Kvidera, Evan D >> wrote: >>> >>> Hello Wireshark Devs, >>> >>> My name is Evan Kvidera and I am a senior undergraduate student studying >>> Computer Science. I have a decent amount of programming experience, but >>> only >>> a little in C. My employer has asked me to try to add support for piping >>> pcap-ng captures to Wireshark. >>> I have read over the bug report requesting the feature, >>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370. >>> >>> After reading the mailing list archives here, >>> https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html, >>> it >>> looks like this addition will be nontrivial, but doable, and that the >>> changes necessary are all going to be in dumpcap. >>> >>> I have at least a month or two of full-time work I can dedicate to this >>> if >>> necessary, although I am hoping it will not take that long. >>> >>> I have read through the Wireshark Developer's Guide and looked over the >>> style guide for Wireshark. Is there anything else I should know before >>> starting development? I will try to develop this as independently as >>> possible, but I may have a few questions along the way. >> >> >> Hi Evan, >> >> I looked at this back in 2012 and even proposed a patch that might be >> useful to you: >> >>http://seclists.org/wireshark/2012/May/25 >> >> No doubt it was a little too simplistic but if I find some time next >> week while I am in Seattle I might try to resurrect it and see if it >> works. > > > I've just encountered a need for this as well. Have you made progress, > Evan? Do you want some help? Evan seems to have dropped off the radar. I outlined to Evan an approach for doing this, so I could send it to Ed instead ... -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On 06/16/2017 01:27 PM, Richard Sharpe wrote: On Fri, Jun 16, 2017 at 9:36 AM, Kvidera, Evan D wrote: Hello Wireshark Devs, My name is Evan Kvidera and I am a senior undergraduate student studying Computer Science. I have a decent amount of programming experience, but only a little in C. My employer has asked me to try to add support for piping pcap-ng captures to Wireshark. I have read over the bug report requesting the feature, https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370. After reading the mailing list archives here, https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html, it looks like this addition will be nontrivial, but doable, and that the changes necessary are all going to be in dumpcap. I have at least a month or two of full-time work I can dedicate to this if necessary, although I am hoping it will not take that long. I have read through the Wireshark Developer's Guide and looked over the style guide for Wireshark. Is there anything else I should know before starting development? I will try to develop this as independently as possible, but I may have a few questions along the way. Hi Evan, I looked at this back in 2012 and even proposed a patch that might be useful to you: http://seclists.org/wireshark/2012/May/25 No doubt it was a little too simplistic but if I find some time next week while I am in Seattle I might try to resurrect it and see if it works. I've just encountered a need for this as well. Have you made progress, Evan? Do you want some help? Ed ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Adding pcap-ng pipe support to dumpcap
On Fri, Jun 16, 2017 at 9:36 AM, Kvidera, Evan D wrote: > Hello Wireshark Devs, > > My name is Evan Kvidera and I am a senior undergraduate student studying > Computer Science. I have a decent amount of programming experience, but only > a little in C. My employer has asked me to try to add support for piping > pcap-ng captures to Wireshark. > I have read over the bug report requesting the feature, > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370. > > After reading the mailing list archives here, > https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html, it > looks like this addition will be nontrivial, but doable, and that the > changes necessary are all going to be in dumpcap. > > I have at least a month or two of full-time work I can dedicate to this if > necessary, although I am hoping it will not take that long. > > I have read through the Wireshark Developer's Guide and looked over the > style guide for Wireshark. Is there anything else I should know before > starting development? I will try to develop this as independently as > possible, but I may have a few questions along the way. Hi Evan, I looked at this back in 2012 and even proposed a patch that might be useful to you: http://seclists.org/wireshark/2012/May/25 No doubt it was a little too simplistic but if I find some time next week while I am in Seattle I might try to resurrect it and see if it works. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Adding pcap-ng pipe support to dumpcap
Hello Wireshark Devs, My name is Evan Kvidera and I am a senior undergraduate student studying Computer Science. I have a decent amount of programming experience, but only a little in C. My employer has asked me to try to add support for piping pcap-ng captures to Wireshark. I have read over the bug report requesting the feature, https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11370. After reading the mailing list archives here, https://www.mail-archive.com/wireshark-dev@wireshark.org/msg6.html, it looks like this addition will be nontrivial, but doable, and that the changes necessary are all going to be in dumpcap. I have at least a month or two of full-time work I can dedicate to this if necessary, although I am hoping it will not take that long. I have read through the Wireshark Developer's Guide and looked over the style guide for Wireshark. Is there anything else I should know before starting development? I will try to develop this as independently as possible, but I may have a few questions along the way. Thanks, Evan ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
