big endian and little endian problem

[DA Ming]

Hi Kerr
Thank you very much for your response.
The problem is that the byte order of some fields of the dhcp packet I
captured in ethereal is reverse to that I printed in gdb.
For example, I filled a char array with 
ip[0] = c0;
ip[1] = a8;
ip[2] = 84;
ip[3] = 02;
However, the packet in ethereal indicates these fields as 0284a8c0,
which should be c0a88402.
Another example is that, a DHCPDISCOVER is sent from client. One of the
fields I filled in vendor specific field (43) is 0x00 01 (1dec, 2 bytes.
This packet is captured by ethereal). However, when I extract these
fields using 'memcpy', the result is 0x01 00 (16dec), which is an
unexpected result. (This is printed with GDB.)
I have not solved this problem yet and it has been blocking me till now.
If you need more information about this to solve this problem, please
tell me ASAP.
Thank you!

                                                              Best
Regards!
DA MING
( +86-25-84731240-5109 / (Alcanet) 2735-5109
@ Ming.Da at alcatel-sbell.com.cn
 
-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
Behalf Of Shane Kerr
Sent: Monday, October 29, 2007 8:17 PM
To: dhcp-users at isc.org
Subject: Re: big endian and little endian problem

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

DA Ming wrote:
> Hi all
> 
> I've just met a problem which seems as a big endian and little endian
one.
> 
> When I send a DHCPDISCOVER to server, and I capture this packet using
> 'ethereal', I see in ethereal that the field 'xid' is 'A9EF68AC'; the
> 'secs' is 0a00.
> 
> However, I print with gdb the option of this packet and find that the
> 'xid' is '2892558249' (dec) = 'AC68EFA9' (hex); the 'secs' is 10 (dec)
=
> 0a (hex).
> 
> I've modified the related source codes in 'Ultrix.h' where
'BYTE_ORDER'
> is set to 'LITTLE_ENDIAN' and changed it to 'BIG_ENDIAN'.
Unfortunately,
> the problem still happens.
> 
> Can anybody help me with it?

Are you having a problem with clients not behaving properly or the
server giving
out leases with incorrect timings or something?

Or is the problem just that the packet looks incorrect in ethereal?

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHJc89MsfZxBO4kbQRAop+AKDNbzzBM2pGhFse1xvX6A0qCpSgowCgvbfS
Ppt2ArYIZGWYtWTI4w/oiig=
=k7bS
-----END PGP SIGNATURE-----