On Mon, Apr 01, 2002 at 05:20:28PM -0500, Mike Frisch wrote:
> Please disregard the last one, I am new...
That patch applied, although it appears to include your previous patch;
that part didn't apply, as it was applied to the code in my tree, which
included your previous patch. I've checked in in.
> 160c183,186
> < ip=((ip&0x000000ff)<<24)|((ip&0x0000ff00)<<8)|((ip&0x00ff0000)>>8)|((ip&0xff000000)>>24);
> ---
> > ip = ((ip & 0x000000ff) << 24) |
> > ((ip & 0x0000ff00) << 8) |
> > ((ip & 0x00ff0000) >> 8) |
> > ((ip & 0xff000000) >> 24);
That code is preceded by
ip = tvb_get_ntohl(tvb, offset);
so you could replace that code, and the "tvb_get_ntohl()",
line with
ip = tvb_get_letohl(tvb, offset);
*However*, I suspect, in practice, that the underlying problem is that
it's an IP address, and "proto_tree_add_ipv4()" expects the IP address
argument to be in *network* byte order, not *host* byte order.
"tvb_get_letohl()" leaves the value alone if you run it on, say, a
little-endian PC, so either "tvb_get_ntohl()" followed by a
byte-swapping, or "tvb_get_letohl()", would do the right thing on a PC.
However, they won't do the right thing on a big-endian machine, such as
a SPARC or PowerPC machine.
Thus, you'd want to do
tvb_memcpy(tvb, (guint8 *)&ip, offset, 4);
to extract the bytes without byte-swapping.
However, given that "ip" isn't actually *used*, you can save yourself
even more trouble by just doing
proto_tree_add_item(tree, hf_hclnfsd_server_ip, tvb, offset, 4, FALSE);
(the last argument doesn't matter for IPv4 addresses, as they're not
FT_UINTn or FT_INTn or FT_BOOLEAN types).
I checked in changes to both places where an IP address was being
fetched to use "proto_tree_add_item()".