Wireshark-dev: Re: [Wireshark-dev] [Bug 3540] incorrect timestamps in netscaler capture file fo

From: Ravi Kondamuru <ravikondamuru@xxxxxxxxx>
Date: Wed, 2 Dec 2009 10:24:54 -0800
Hi Stig,

Based on comments from Guy Harris and Bill Meier, I have attached a patch to
make the netscaler wiretap code independent of the host system endian-ness.
I have taken care of (1) reading and writing nstrace files (netscaler.c) and
(2) reading in dissector code (packet-nstrace.c) also.

Please review for commit.

thanks,
Ravi.

On Wed, Nov 18, 2009 at 1:55 PM, <bugzilla-daemon@xxxxxxxxxxxxx> wrote:
--- Comment #25 from Guy Harris <guy@xxxxxxxxxxxx>  2009-11-18 13:55:38 PDT ---
> I dont see any definitions for letoh[sl]. However there are pletoh[sl] (epan\pInt.h) macros.

Those macros are also in <wiretap/wtap-int.h>; you should use those, not the
ones in <epan/pint.h>, in Wiretap modules such as netscaler.c

> These definitions are not ifdef-ed in __ppc__ like how GUINT_TO_BE (Glibconfig.h) macros are done.

Ifdeffing with __ppc__ is neither necessary nor sufficient.  pletoh[sl] extract
the bytes, one at a time, and assemble them into a 16-bit or 32-bit quantity;
that is a byte-order-independent operation, so no ifdeffing is necessary.  This
also means that they work regardless of whether the quantity being fetched is
aligned on the appropriate boundary or not.

(Ifdeffing with __ppc__ is not sufficient because PowerPC and other flavors of
the Power Architecture are not the only big-endian architectures in existence.
The only reason they're ifdeffed in GLib is that GLib has optimized versions of
PowerPC.)

> There are lots of users of these macros. Are they susceptible to the same issue?

No, they are not.  Those macros do the right thing on both little-endian and
big-endian machines.

Note also that when *writing* a Netscaler dump, you must convert
host-byte-order values *to* little-endian.  See the htole[ls] macros in
wtap-int.h.


--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.