endian issue in conntrack_netlink

endian issue in conntrack_netlink

[Pablo Neira]

Hi Harald,

while working on the conntrack tool I've observed that conntrack_netlink 
  uses cpu_to_be64, htonl... to flip bits depending on the architecture. 
Is this some kind of portability issue?

BTW, what is the equivalence of be64_to_cpu in userspace? Thanks!

--
Pablo

Re: endian issue in conntrack_netlink

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

On Thu, Aug 25, 2005 at 11:09:24PM +0200, Pablo Neira wrote:
> Hi Harald,
> 
> while working on the conntrack tool I've observed that conntrack_netlink  uses cpu_to_be64, 
> htonl... to flip bits depending on the architecture. Is this some kind of portability issue?

yes, it means that all the payload of any nfattr will always be in
network byte order.  This would allow easy transport over a real network
in the future (e.g. jamal's netlink2).

The nlmsghdr and the nfattr headers (type and length) are still host
byte order.  But some easy program (e.g. the deamon that receives from
netlink and send sover real network) can just iterate over them and
convert them to network byte order - without understanding anything
about the payload.

> BTW, what is the equivalence of be64_to_cpu in userspace? Thanks!

Good question.  I don't think there's a standard way [yet?], so I'd
suggest manually implementing it by "#if little endian" bitshift
operations in C (at least for now).

Cheers,

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]