On Mon, Oct 15, 2012 at 09:55:09PM -0700, Ansis Atteka wrote:
[...]
> >> Here is how I am currently doing that:
> >>
> >> struct nethdr {
> >> #if __BYTE_ORDER == __LITTLE_ENDIAN
> >> uint8_t type:4,
> >> version:4;
> >> #elif __BYTE_ORDER == __BIG_ENDIAN
> >> uint8_t version:4,
> >> type:4;
> >> #else
> >> #error "Unknown system endianess!"
> >> #endif
> >> uint8_t flags;
> >> uint16_t len;
> >> uint32_t seq;
> >> uint32_t nsid; < -present only if nethdr.flag &
> >> };
> >> nsid is the namespace id. This field would be present only
> >> if nethdr.flags & NET_F_NAMESPACE != 0.
> >
> > That adds an always zero field for the non-namespace case in the
> > protocol fixed header. TLVs can be used for optional fields.
>
> What is your take on encapsulating namespace id in control messages
> (e.g. state resync requests)?
>
> It seems that as of now control messages do not have TLVs...
>
> Of course I could put some logic inside build.c and parse.c to deal
> with that. For example, if caller passes NULL for nf_conntrack *ct,
> then that would handle control message case?
>
> Any better ideas?
It took me a long while to decide on this, sorry for the delay.
I think adding some 32-bits ID to the nethdr is fine since I can reuse
in case I decide to support cluster-based firewall clusters composed
of more than two firewalls.
The ID will allows us to identify messages coming from different
firewall and to keep different external caches, one per node ID.
So go ahead with adding that ID to the nethdr.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
