[Olsr-dev] Strange shift behaviour (ipcalc.c)

[Markus Kittenberger]

Hi

i just tracked down a strange bug, but still don`t understand why it is a
bug (-;

i have and had the http-plugin configured like this,

  PlParam "Net" "0.0.0.0 0.0.0.0"

so everybody could access the http-plugin, and it worked as expected,..

as i upgraded the olsrd from 0.5.6r2 to head (54b2ca51a0b1)

only localhost oculd connect to http plugin

i checked around findiun that other netmasks worked e.g. /24 or /1, but not
/0

so i startet to debug the code,..

i ended in ipcalc.c

121 if(olsr_cnf->ip_version == AF_INET) {
122  uint32_t netmask = ntohl(~0 << (32 - net->prefix_len));
123  rv = (ipaddr->v4.s_addr & netmask) == (net->prefix.v4.s_addr &
netmask);
124 }

~0 in my understanding is 11111111111111111111111111111111

the prefix_len was correctly 0 for 0.0.0.0/0

so netmask should get 32 zeros shifted in from the right, ending in having
only zeros and a value of 0

but it was still 2^32 at line 123, and ip_in_net returned false, and
hhhtpinfo rejected the connection,..

i changed the code like this to make it working, but i still don`t
understand why above code doesnt work, and why the simlar code in 0.5.6r2
did work,..

if(olsr_cnf->ip_version == AF_INET) {
  uint32_t netmask = ~0;
  if (net->prefix_len==0) netmask=!netmask; else netmask=ntohl(netmask <<
(32 - net->prefix_len));
  rv = (ipaddr->v4.s_addr & netmask) == (net->prefix.v4.s_addr & netmask);
}

in 0.5.6r2 it was infact the same code, just custom olsr types have been
used, so wtf?

it was compiled 1 week ago with same compiler on same machine, so wtf?

if(olsr_cnf->ip_version == AF_INET) {
 olsr_u32_t netmask = ~0 << (32 - net->prefix_len);
 rv = (ipaddr->v4.s_addr & netmask) == (net->prefix.v4.s_addr & netmask);
}

so i will now step back to 0.5.6r2 to find out why and how this code
workes,..

Or has anybody an explanation for this??

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20081129/5617add7/attachment.html>