Endianness and comparing IP's

Endianness and comparing IP's

[alex avriette]

I am still working with the opennap software (available at
opennap.sourceforge.net) to resolve a strange issue whereby two IP's are
reported as equal, but fail a conditional for equality. the code in
question is here:

  if (BSWAP32(ip) != con->ip)
  {
    log ("server_login: ip=%u con->ip=%u", BSWAP32(ip), con->ip);
    log ("server_login: %s does not match %s (%s)",
         con->host, fields[0], my_ntoa (ip));
    con->destroy;
    return;
   }

the output of this is here:

server_login: ip=523706576 con->ip=523706576
server_login: 208.32.55.31 does not match cygnus.theblackmoor.net
(208.32.55.31)

so what I see happening is that BSWAP32(ip) doesnt equal con->ip which is
reported by the log (as seen earlier on the list, it uses a v*printf
followed by a fputs) as indeed being equal. I dont have host entries for
this host nor any of the other hosts I am trying to connect to.

Apparently this software is developed on x86 machines and tested in
Solaris on Suns for big endian compatibility. The code works fine on PC's
in this configuration:

    if (ip != BSWAP32 (con->ip))
    {
      log ("server_login: %s does not match %s (%s)",
           con->host, fields[0], my_ntoa (ip));
      con->destroy;
      return;
    }

I am not familiar with the concept of endianness and it hasnt quite been
explained sufficiently to me. I have Cc'ed the primary developer of
opennap on this message, though I am pretty familiar with the concepts and
workings of the code.

Thanks in advance.

alex


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Jerome L Quinn]

Check your types.  I suspect that you've got an implicit typecast between
unsigned int and something else going on.  So printf gives you the right
results, but the actual compare does not.

Jerry Quinn



alex avriette <alex@macachu.yi.org>@lists.linuxppc.org on 01/05/2001
03:25:00 PM

Please respond to <alex@cosmo.allay.net>

Sent by:  owner-linuxppc-dev@lists.linuxppc.org


To:   <linuxppc-dev@lists.linuxppc.org>
cc:   <drscholl@users.sourceforge.net>
Subject:  Endianness and comparing IP's




I am still working with the opennap software (available at
opennap.sourceforge.net) to resolve a strange issue whereby two IP's are
reported as equal, but fail a conditional for equality. the code in
question is here:

  if (BSWAP32(ip) != con->ip)
  {
    log ("server_login: ip=%u con->ip=%u", BSWAP32(ip), con->ip);
    log ("server_login: %s does not match %s (%s)",
         con->host, fields[0], my_ntoa (ip));
    con->destroy;
    return;
   }

the output of this is here:

server_login: ip=523706576 con->ip=523706576
server_login: 208.32.55.31 does not match cygnus.theblackmoor.net
(208.32.55.31)

so what I see happening is that BSWAP32(ip) doesnt equal con->ip which is
reported by the log (as seen earlier on the list, it uses a v*printf
followed by a fputs) as indeed being equal. I dont have host entries for
this host nor any of the other hosts I am trying to connect to.

Apparently this software is developed on x86 machines and tested in
Solaris on Suns for big endian compatibility. The code works fine on PC's
in this configuration:

    if (ip != BSWAP32 (con->ip))
    {
      log ("server_login: %s does not match %s (%s)",
           con->host, fields[0], my_ntoa (ip));
      con->destroy;
      return;
    }

I am not familiar with the concept of endianness and it hasnt quite been
explained sufficiently to me. I have Cc'ed the primary developer of
opennap on this message, though I am pretty familiar with the concepts and
workings of the code.

Thanks in advance.

alex


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

RE: Endianness and comparing IP's

[Clayton,Keith - Programmer]

Is the BSWAP32 macro a destructive macro . . destructive in the sense that
the value ip is modified?

If so, you run BSWAP32(ip) in the condition and ip is modified.  Conditional
fails . . pass ip through BSWAP32 again and the byte order is back to the
original!

Its quite possible that ip is coming to you in a form that is already
byte-order correct . .

Try this . . remove all the BSWAP32 refs and before the condition put in
this line

log ("server_login: ip=%u con->ip=%u", ip, con->ip);


I'd venture a guess that ip will show as equivalent to con->ip . . so the
use of BSWAP32 here is incorrect


Keith Clayton
Programmer/Analyst, Lake Tahoe Community College
clayton@ltcc.cc.ca.us

"If you don't trust me with your source code, why should I trust you with my
computer"

No electrons were harmed in the creation of this email

> -----Original Message-----
> From:	alex avriette [SMTP:alex@macachu.yi.org]
> Sent:	Friday, January 05, 2001 12:25 PM
> To:	linuxppc-dev@lists.linuxppc.org
> Cc:	drscholl@users.sourceforge.net
> Subject:	Endianness and comparing IP's
>
>
> I am still working with the opennap software (available at
> opennap.sourceforge.net) to resolve a strange issue whereby two IP's are
> reported as equal, but fail a conditional for equality. the code in
> question is here:
>
>   if (BSWAP32(ip) != con->ip)
>   {
>     log ("server_login: ip=%u con->ip=%u", BSWAP32(ip), con->ip);
>     log ("server_login: %s does not match %s (%s)",
>          con->host, fields[0], my_ntoa (ip));
>     con->destroy;
>     return;
>    }
>
> the output of this is here:
>
> server_login: ip=523706576 con->ip=523706576
> server_login: 208.32.55.31 does not match cygnus.theblackmoor.net
> (208.32.55.31)
>
> so what I see happening is that BSWAP32(ip) doesnt equal con->ip which is
> reported by the log (as seen earlier on the list, it uses a v*printf
> followed by a fputs) as indeed being equal. I dont have host entries for
> this host nor any of the other hosts I am trying to connect to.
>
> Apparently this software is developed on x86 machines and tested in
> Solaris on Suns for big endian compatibility. The code works fine on PC's
> in this configuration:
>
>     if (ip != BSWAP32 (con->ip))
>     {
>       log ("server_login: %s does not match %s (%s)",
>            con->host, fields[0], my_ntoa (ip));
>       con->destroy;
>       return;
>     }
>
> I am not familiar with the concept of endianness and it hasnt quite been
> explained sufficiently to me. I have Cc'ed the primary developer of
> opennap on this message, though I am pretty familiar with the concepts and
> workings of the code.
>
> Thanks in advance.
>
> alex
>
>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Iain Sandoe]

IIRC IP addresses are defined as big-endian in which case they should not
need swapping for PPC.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Iain Sandoe]

I wrote:
> IIRC IP addresses are defined as big-endian in which case they should not
> need swapping for PPC.

sorry, that's not very helpful...

more to the point is that there are a set of macros/functions designed for
this purpose (try man htons)... which avoids thinking to hard about
transferring between endian-ness of machines.

I'm not sure why the BSWAP32 is being used instead of one of the network
macros... maybe a red-herring but...

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[drscholl]

On Sat, Jan 06, 2001 at 12:22:33AM +0000, Iain Sandoe wrote:
> more to the point is that there are a set of macros/functions designed for
> this purpose (try man htons)... which avoids thinking to hard about
> transferring between endian-ness of machines.
>
> I'm not sure why the BSWAP32 is being used instead of one of the network
> macros... maybe a red-herring but...

Unfortunately Napster, Inc. chose to use little-endian format IP addresses
in the protocol, so the traditional htonl() macros aren't useful in
this case.  What gets stored in the context for the connection is the
little-endian version so that each time the ip address is sent as part
of the protocol, there is no need for bit manipulation.  The particular check
that Alex set has the IP address in network byte order (from the
gethostbyname() call), so its *required* that the bits be swapped to check
against what is stored in the context.

All of the ints in question are unsigned, so there isn't an issue of
conversion (I beleive gcc -W -Wall -pedantic would have warned if you
tried to do a comparison of different types, anyway).

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Iain Sandoe]

Sat, Jan 6, 2001, drscholl wrote:

>> more to the point is that there are a set of macros/functions designed for
>> this purpose (try man htons)... which avoids thinking to hard about
>> transferring between endian-ness of machines.
>>
>> I'm not sure why the BSWAP32 is being used instead of one of the network
>> macros... maybe a red-herring but...
>
> Unfortunately Napster, Inc. chose to use little-endian format IP addresses
> in the protocol,

sheesh...

> so the traditional htonl() macros aren't useful in
> this case.  What gets stored in the context for the connection is the
> little-endian version so that each time the ip address is sent as part
> of the protocol, there is no need for bit manipulation.  The particular check
> that Alex set has the IP address in network byte order (from the
> gethostbyname() call), so its *required* that the bits be swapped to check
> against what is stored in the context.

fair enough. (I did admit it might be a red-herring ;-)

> All of the ints in question are unsigned, so there isn't an issue of
> conversion (I beleive gcc -W -Wall -pedantic would have warned if you
> tried to do a comparison of different types, anyway).

probably (but it wouldn't be difficult to check that anyway).

What is the code for the BSWAP32 macro?
...and what asm does it produce?
(or does it use __asm() statements?)

(or are you convinced it is OK?)

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[drscholl]

On Sat, Jan 06, 2001 at 10:28:48PM +0000, Iain Sandoe wrote:
> > All of the ints in question are unsigned, so there isn't an issue of
> > conversion (I beleive gcc -W -Wall -pedantic would have warned if you
> > tried to do a comparison of different types, anyway).
>
> probably (but it wouldn't be difficult to check that anyway).

Yes, I did verify that they are all unsigned int, not just relying on
that.  :-)

> What is the code for the BSWAP32 macro?
> ...and what asm does it produce?
> (or does it use __asm() statements?)

/* convert the bytes of a 32-bit integer to little endian */
#define BSWAP32(c)
((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24)

> (or are you convinced it is OK?)

Seems to work fine under Solaris, otherwise nobody would be able to
download anything because the IP address would be reversed.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Iain Sandoe]

Sat, Jan 6, 2001, drscholl wrote...
[...]
>> probably (but it wouldn't be difficult to check that anyway).
> Yes, I did verify that they are all unsigned int, not just relying on
> that.  :-)

hmmm. I suppose that the literals in the macro are int by definition?

> /* convert the bytes of a 32-bit integer to little endian */
> #define BSWAP32(c)
> ((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24)
>> (or are you convinced it is OK?)
> Seems to work fine under Solaris, otherwise nobody would be able to
> download anything because the IP address would be reversed.

works OK for me too under linuxppc (with default compiler options - got
anything weird specified?).

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Iain Sandoe]

> /* convert the bytes of a 32-bit integer to little endian */
> #define BSWAP32(c)
> ((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24)

 #define BSWAP32(c) \
(((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24))


will work as you expect it too... ;-)

precedence is a funny thing...

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Keith Clayton]

Good catch!


On Sat, Jan 06, 2001 at 11:37:24PM +0000, Iain Sandoe wrote:
>
>
> > /* convert the bytes of a 32-bit integer to little endian */
> > #define BSWAP32(c)
> > ((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24)
>
>  #define BSWAP32(c) \
> (((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24))
>
>
> will work as you expect it too... ;-)
>
> precedence is a funny thing...
>
> Iain.
>
>

--
<><><><><><><><><><><><>
Keith Clayton
clay-ton@pacbell.net

"If you don't trust me with your source code,
            why should I trust you with my computer?"

GPG key: http://www.jps.net/kclayton/keith_public_key.html
         http://www.keyserver.net

GPG fingerprint: 0C47 F1A1 0434 588C 9457  D53F D86A 5449 43F6 09A0


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[Geert Uytterhoeven]

On Sat, 6 Jan 2001, Iain Sandoe wrote:
> > /* convert the bytes of a 32-bit integer to little endian */
> > #define BSWAP32(c)
> > ((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24)
>
>  #define BSWAP32(c) \
> (((c>>24)&0xff)|((c>>8)&0xff00)|((c<<8)&0xff0000)|(c<<24))
>
>
> will work as you expect it too... ;-)
>
> precedence is a funny thing...

Similarly, replace `c' by `(c)'.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Endianness and comparing IP's

[alex avriette]

Thank you all. The problem has been solved. solution (as per Iain and
Geert):

#define BSWAP32(c)
((((c)>>24)&0xff)|(((c)>>8)&0xff00)|(((c)<<8)&0xff0000)|((c)<<24))


thanks again.
alex


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/