Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: RE: [Ethereal-dev] (possible) Packet Fence Patch for CVS

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Visser, Martin (SNO)" <Martin.Visser@xxxxxxxxxx>
Date: Fri, 23 Mar 2001 06:28:26 +0800
I've a work-in-progress that has already addressed 3 and 4, and will do the
others (plus a whole lot more)  soon

Martin Visser
Technology Consultant - Compaq Global Services

Compaq Computer Australia
410 Concord Road
Rhodes, Sydney NSW 2138
Australia

Phone: +61-2-9022-5630
Mobile: +61-411-254-513
Fax:+61-2-9022-7001
Email:martin.visser@xxxxxxxxxx


> -----Original Message-----
> From: Guy Harris [mailto:gharris@xxxxxxxxxxxx]
> Sent: Tuesday, 13 March 2001 6:10 PM
> To: Guy Harris
> Cc: Paul Schulz; ethereal-dev@xxxxxxxxxxxx; pschulz@xxxxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] (possible) Packet Fence Patch for CVS
> 
> 
> On Mon, Mar 12, 2001 at 11:48:11AM -0800, Guy Harris wrote:
> > It might also be fixed by changing the packet fence code to include
> > "dfilter/dfilter.h", rather than just "dfilter.h", which is what the
> > code in Ethereal does.
> > 
> > If that fixes it,
> 
> It does, but the correct fix is not to include it at all!  
> It, like many
> of the other header files include by "packet_fence.c", doesn't need to
> be included.
> 
> Here's a version of the packet fence patch, plus "packet_fence.h" and
> "packet_fence.c", that
> 
> 	1) is a patch against the current code in CVS, rather than an
> 	   old version of Ethereal;
> 
> 	2) includes a *lot* fewer header files in "packet_fence.c" (only
> 	   the ones that are needed are included - and
> 	   "dfilter/dfilter.h" is not one that's needed...);
> 
> 	3) calls "packet_fence_update_ruler()" after creating the ruler,
> 	   so that the upper and lower limits of the ruler's range are
> 	   set very early in its life - without that, Ethereal crashed
> 	   when started up, as both limits were zero when the ruler was
> 	   exposed, and, when trying to compute something that involved
> 	   dividing by the difference between those limits, it got a
> 	   zero divide fault);
> 
> 	4) fixes up some errors in "gtkclist.c" (you can't use
> 	   "g_return_if_fail()" in a non-void function, you have to use
> 	   "gtk_return_val_if_fail()".
> 
> Martin, you should probably update your version of the packet 
> fence code
> with these versions, and update the patch.
>