error_string = register_tap_listener("frame", &the_tapinfo_struct,
NULL,
(void*)frame_reset, (void*)frame_packet,
(void*)frame_draw);
In the code above you specify NULL as the filter and thus tap will
give you an unfiltered view of the packets.
Replace this with "foo" if you only want packets matching "foo".
Can you please create a patch for the readme files and examples if
this behaviour was unclear so that others are not bitten by this doc
bug.
On Tue, 2 Nov 2004 14:14:26 +1100, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> The tap system is by design decoupled from the display filters
> applied to the main window.
>
> If you want to push a filtered subset of all packets to the TAP, then
> you have to specify the appropriate filter string to the call you use
> when you register the tap listener.
>
> display filters on the main window do not affect which packets the tap
> listener receives, the tap listener itself controls this.
>
>
>
>
> On Sat, 30 Oct 2004 12:56:23 +0200, Koen Smets <koen.smets@xxxxxxxxx> wrote:
> > Dear (readers of the) list,
> >
> > We're making some progress with our project (see: "Extract data from
> > Ethereal" posted on Oct. 19).
> >
> > Exploring some ideas, we've realised writing an extension that taps
> > "Frames" (based on rtp_stream.c en rpc_stat.c), but it doesn't behave
> > exactly like we figured out:
> >
> > When we start ethereal from xterm, we see that the tap gets registered
> > and when we load in an existing capture file. We get no output.
> > Reason:I've figured out that the flags.passed_dfilter are set after
> > our frame_packet is called).
> >
> > Also when we set a display filter, click apply the previous list is
> > printed out instead of the restricted output (which we see in
> > packet_list). When we clear display filter, our filtered output is
> > printed to stdout (but packet_list shows the unfiltered data).
> >
> > How can we synchronise our tap with packet_list? So that we can use
> > the tap system to send data to our server application?
> >
> > The second problem we have is the following (and is also packet_list
> > related). When we use the capture capabilities of Ethereal ("Update
> > list of packets in real time), our function frame_packet isn't called
> > Although we think, that packets are being dissected the right way
> > (because when a packet added to the packet list, has the right
> > protocol and info set by the corresponding dissectors).
> > This has probably to do with the fact that Ethereal forks a child
> > process that does the capturing (and also the dissecting???).
> >
> > So what we like to do is: every time a packet gets added to the list
> > of packets, our tap gets called and from that point we'll perform some
> > magic to send the data to our server.
> >
> > Hopefully some can put us back on the right track!
> >
> > With regards,
> >
> > Koen Smets
> >
> > PS: here's is our sample code (it doesn't do very much, but we're just
> > exploring tapping works and how to extract data), also we've left out,
> > init, draw and reset functions:
> >
> > typedef struct _frame_tapinfo {
> >
> > } frame_tapinfo_t;
> >
> > int
> > frame_packet(frame_tapinfo_t *tapinfo _U_, packet_info *pinfo,
> > epan_dissect_t *edt _U_, char *data _U_)
> > {
> > if (pinfo->fd->flags.passed_dfilter){
> > printf("Frame number: %d\n",pinfo->fd->num);
> > }
> > return 0;
> > }P
> >
> > void
> > register_tap_listener_frame(void)
> > {
> > printf("register_tap_listener_frame(void)\n");
> >
> > GString *error_string;
> >
> > register_ethereal_tap("frame", frame_init_tap);
> >
> > error_string = register_tap_listener("frame", &the_tapinfo_struct,
> > NULL,
> > (void*)frame_reset, (void*)frame_packet,
> > (void*)frame_draw);
> >
> > if (error_string != NULL) {
> > simple_dialog(ESD_TYPE_ERROR, ESD_BTN_OK,
> > error_string->str);
> > g_string_free(error_string, TRUE);
> > exit(1);
> > }
> > }
> >
> > --
> > Programming today is a race between software engineers striving to
> > build bigger and better idiot-proof programs, and the Universe trying
> > to produce bigger and better idiots. So far, the Universe is winning.
> > --Rich Cook--
> >
> > _______________________________________________
> > Ethereal-dev mailing list
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
>
