ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] (no subject)

From: John Sullivan <jsethdev@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, 23 Jun 2008 19:12:57 +0100
On Monday, June 23, 2008, 6:38:16 PM, Martin Corraine (mcorrain) wrote:
> In the readme.developer, it states you shouldn't use "tvb_get_ntohl(tvb,
> offset);"  I tried using tvb_get_letohl (tvb, offset);"  However, it
> retrieves the data backwards thus retrieving the wrong value. Any
> suggestions?

What it actually says is:

    Don't use "ntohs()", "ntohl()", "htons()", or "htonl()"; the header
    files required to define or declare them differ between platforms,

This is talking just about the functions with those names - it says
nothing about the wireshark-provided alternatives called g_ntohl(),
tvb_get_ntohl() etc. These are safe platform-independant versions that
you are expected to use (in the appropriate circumstances.)

Then:

    Don't fetch a little-endian value using "tvb_get_ntohs() or
    "tvb_get_ntohl()" and then using "g_ntohs()", "g_htons()", "g_ntohl()",
    or "g_htonl()" on the resulting value

Here it is saying don't use tvb_get_ntohl() *followed* by g_ntohl(),
in the expectation that the second call will byte-swap. On a naturally
big-endian machine, g_ntohl() does nothing. This says nothing about
calling tvb_get_ntohl() *on its own*, where that is the appropriate
thing to do.

> For instance,
 
> "00 00 00 06 " should be 6 in base 10 (I'm sure it should be read this
> way). However, I get 1610612736 with tvb_get_letohl() becasue it reads
> it "60 00 00 00"

In your example, the value is trasmitted in big-endian (AKA network)
byte order already, not little-endian, so the right thing is to use
tvb_get_ntohl() to retrieve it. This will produce the correct result
on all platforms.

John
-- 
Dead stars still burn