[radvd-devel-l] [PATCH] Add support for NEMO Basic

[Ville Nuorvala]

Pekka Savola wrote:

> I'm a bit troubled by this:
> 
> +#ifndef ND_OPT_HAI_FLAG_SUPPORT_MR
> +#if BYTE_ORDER == BIG_ENDIAN
> +#define ND_OPT_HAI_FLAG_SUPPORT_MR     0x8000
> +#else /* BYTE_ORDER == LITTLE_ENDIAN */
> +#define ND_OPT_HAI_FLAG_SUPPORT_MR     0x0080
> +#endif
> +#endif
> 
> .. the code we're using right now doesn't need to make distinction 
> between BE and LE (or maybe certain features just don't work :). Would 
> designing this so that making one isn't needed be feasible?

Until now radvd has only needed 8-bit flag fields, but this is 
unfortunately a 16-bit one. What exactly troubles you about the 
definition? Are you worried the BYTE_ORDER check won't work on all 
platforms?

I'm only familiar with gcc and glibc, so I'm not sure what happens if 
you use another compiler or other headers, but at least the glibc 
version of netinet/icmp6.h defines multi-byte fields (such as the 
Neighbor Advertisement flags) in network byte order just like I defined 
ND_OPT_HAI_FLAG_SUPPORT_MR.

Radvd *could* of course define its own constants in host byte order and 
use hton[s|l] to convert these into network byte order. However, in the 
current code all locally defined RA flag definitions from defaults.h are 
overridden by the (network byte order) ones from netinet/icmp6.h. This 
won't of course cause problems with the old one-byte values, but will do 
so with any multi-byte ones.

Regards,
Ville
-- 
Ville Nuorvala
Researcyh Assistant,
Laboratory for Theoretical Computer Science,
Helsinki University of Technology
email: vnuorval at tcs.hut.fi, phone: +358 (0)9 451 5257