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