Hi Pablo, thanks for you quick response.
Op 12/01/2018 om 1:21 schreef Pablo Neira Ayuso:
> Hi Thierry,
>
> On Thu, Jan 11, 2018 at 07:42:27PM +0100, Thierry Du Tre wrote:
>> This is a patch proposal to support shifted ranges in portmaps.
>
> I think you can get a much smaller patch if you rename the existing
> "struct nf_nat_range" to "struct nf_nat_range_old", then the idea is
> to dump the old representation into the new one, something like:
>
> struct nf_nat_range range = {};
>
> memcpy(&range, range_old, sizeof(range_old));
I did think about this but then checked other xt modules with multiple revisions :
xt_hashlimit.c - struct xt_hashlimit_mtinfo3
xt_conntrack.c - struct xt_conntrack_mtinfo3
xt_mark.c - struct xt_mark_tginfo2
But you prefer changing uapi/linux/netfilter/nf_nat.h with something like this ?
+struct nf_nat_range1 {
+ unsigned int flags;
+ union nf_inet_addr min_addr;
+ union nf_inet_addr max_addr;
+ union nf_conntrack_man_proto min_proto;
+ union nf_conntrack_man_proto max_proto;
+};
+
struct nf_nat_range {
unsigned int flags;
union nf_inet_addr min_addr;
union nf_inet_addr max_addr;
union nf_conntrack_man_proto min_proto;
union nf_conntrack_man_proto max_proto;
+ union nf_conntrack_man_proto base_proto;
};
In your reply to my first patch proposal you mentioned the backwards compatibility problem regarding userspace applications.
The new revisions for SNAT and DNAT target do keep ABI constant, but changing the current nf_nat_range definition will impact API (although it won't trigger any compile errors because new nf_nat_range is a simple superset of the current definition).
Is that ok for you then ?
--
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
