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] [Patch] native little endian ipv4 decoding function for the

From: "Luis Ontanon" <luis.ontanon@xxxxxxxxx>
Date: Wed, 11 Apr 2007 20:22:31 +0200
On 4/11/07, Guy Harris <guy@xxxxxxxxxxxx> wrote:
Balint Reczey (IJ/ETH) wrote:

> The attached patch adds ability of reading Little Endian encoded IPv4
> addresses to the Lua plugin.

What exactly are the semantics of TvbRange_get_ipv4() and
TvbRange_get_le_ipv4() supposed to be?

The current tvbrange:get_ipv4() fetches the IPv4 address using tvb_get_ntohl()

I guess (I haven't seen the patch yet) that tvbrange:get_le_ipv4()
would fetch a Little endian IPv4 using tvb_get_letohl()

Note, for example, that the value passed to SET_ADDRESS() should be the
*raw* bytes of the IPv4 address, *NOT* the value as processed by, for
example, tvb_get_ntohl() or g_ntohl().  The same applies to the value
passed to proto_tree_add_ipv4().

Any code that uses tvb_get_ntohl() to get an IPv4 address will fail on a
little-endian machine - and will often be "fixed" by the developer by
changing the call to tvb_get_letohl(), which will fail on a big-endian
machine (such as the machine on which I'm typing this).

I suspect that TvbRange_get_ipv4() should use tvb_get_ipv4() to fetch
the IPv4 address, at least fro the value passed to SET_ADDRESS().

No, it uses tvb_get_ntohl().


If the purpose of TvbRange_get_le_ipv4() is to fix problems seen with
Lua scripts on little-endian machines, the right fix might be to fix
TvbRange_get_ipv4().

If the purpose is to handle packets where an IPv4 address is not stored
in network byte order - that's *very* rare, but it's not unheard of -
then, if TvbRange_get_ipv4() needs to use tvb_get_ipv4(),
TvbRange_get_le_ipv4() should use tvb_get_ipv4() and then byte-swap the
value.

As I have never tested this code on a LE machine (I have one now so
I'll take a look at it later)
as this might be the case.

Please verify this assumption:

I should not do any processing on the bytes of an IPv4 address because
regardless of endianity it is always interpreted as a guint8[4] where
[0] contains the first byte. so that 10.11.12.13 would always be
stored regardless of the endianity as 0a:0b:0c:0d.

Is that correct?

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan