NAT reservations
Subsystems (2)
RFC PATCH 1/1 NAT reservations
Hi,
I've prepared the first public version of the NAT reservation patch. It
provides roughly the same interface which was discussed here earlier. However, this is not yet tested at all, apart from that seeing that NAT still works after applying... :) So, I'm waiting for comments regarding the patch, especially I'd need help in the following:
1. When registering a new reservation, it should be made sure that not
only that it wasn't already registered, but that it is also not clashing with an already existing conntrack entry. However, we only have a struct ip_conntrack_manip at registration, so how could we check that?
2. Some testing if reservations are really reserved, and not allocated
by NAT unless explicitly requested.
Any feedback is welcome. :)
Signature · 2 lines
Regards,
Krisztian KOVACSinclude/linux/netfilter_ipv4/ip_conntrack.h +5 -0
@@ -140,6 +140,9 @@/* Timer function; deletes the expectation. */ struct timer_list timeout; +/* List of registered reservations */ +struct list_head reserved_list; +/* Data filled out by the conntrack helpers follow: */ /* We expect this tuple, with the following mask */
@@ -249,6 +252,8 @@/* These are for NAT. Icky. */ /* Call me when a conntrack is destroyed. */ extern void (*ip_conntrack_destroyed)(struct ip_conntrack *conntrack); +/* Call when an expectation is destroyed. */ +extern void (*ip_conntrack_expect_destroyed)(struct ip_conntrack_expect *exp);/* Returns new sk_buff, or NULL */ struct sk_buff *
include/linux/netfilter_ipv4/ip_nat.h +40 -2
65 lines not on this page · raw message
net/ipv4/netfilter/ip_conntrack_core.c +4 -0
@@ -56,6 +56,7 @@DECLARE_RWLOCK (ip_conntrack_expect_tuple_lock);void (*ip_conntrack_destroyed)(struct ip_conntrack *conntrack) =NULL ; +void (*ip_conntrack_expect_destroyed)(struct ip_conntrack_expect *expect) =NULL ;LIST_HEAD (ip_conntrack_expect_list);LIST_HEAD (protocol_list);static LIST_HEAD (helpers);
@@ -177,6 +178,9 @@DEBUGP ("destroy_expect(%p) use=%d\n" , exp,atomic_read (&exp->use));IP_NF_ASSERT (atomic_read (&exp->use));IP_NF_ASSERT (!timer_pending (&exp->timeout)); + +if (ip_conntrack_expect_destroyed) +ip_conntrack_expect_destroyed (exp);kfree (exp); }
net/ipv4/netfilter/ip_conntrack_standalone.c +1 -0
@@ -478,6 +478,7 @@EXPORT_SYMBOL (ip_ct_gather_frags);EXPORT_SYMBOL (ip_conntrack_htable_size);EXPORT_SYMBOL (ip_conntrack_expect_list); +EXPORT_SYMBOL (ip_conntrack_expect_destroyed);EXPORT_SYMBOL (ip_conntrack_lock);EXPORT_SYMBOL (ip_conntrack_hash);EXPORT_SYMBOL_GPL (ip_conntrack_find_get);
net/ipv4/netfilter/ip_nat_core.c +280 -6
361 lines not on this page · raw message
net/ipv4/netfilter/ip_nat_proto_icmp.c +1 -1
@@ -36,7 +36,7 @@for (i =0 ; i < range_size; i++, id++) { tuple->src.u.icmp.id = range->min.icmp.id + (id % range_size); -if (!ip_nat_used_tuple (tuple, conntrack)) +if (!ip_nat_used_tuple (tuple, conntrack, maniptype, range->flags))return 1 ; }return 0 ;
net/ipv4/netfilter/ip_nat_proto_tcp.c +1 -1
@@ -66,7 +66,7 @@for (i =0 ; i < range_size; i++, port++) { *portptr =htons (min + port % range_size); -if (!ip_nat_used_tuple (tuple, conntrack)) { +if (!ip_nat_used_tuple (tuple, conntrack, maniptype, range->flags)) {return 1 ; } }
net/ipv4/netfilter/ip_nat_proto_udp.c +1 -1
@@ -66,7 +66,7 @@for (i =0 ; i < range_size; i++, port++) { *portptr =htons (min + port % range_size); -if (!ip_nat_used_tuple (tuple, conntrack)) +if (!ip_nat_used_tuple (tuple, conntrack, maniptype, range->flags))return 1 ; }return 0 ;
net/ipv4/netfilter/ip_nat_standalone.c +6 -0
@@ -356,4 +356,10 @@EXPORT_SYMBOL (ip_nat_mangle_tcp_packet);EXPORT_SYMBOL (ip_nat_mangle_udp_packet);EXPORT_SYMBOL (ip_nat_used_tuple); +EXPORT_SYMBOL (ip_nat_reserved_register); +EXPORT_SYMBOL (__ip_nat_reserved_new_hash); +EXPORT_SYMBOL (__ip_nat_reserved_unhash); +EXPORT_SYMBOL (__ip_nat_reserved_free); +EXPORT_SYMBOL (ip_nat_reserved_unregister); +EXPORT_SYMBOL (ip_nat_reserved_unregister_all);MODULE_LICENSE ("GPL" );
Quoted 4 lines · KOVACS Krisztian
Hi,
Any feedback is welcome. :)
Looks fine so far, however two cosmetic remarks:
don't change existing definitions for bits in bitmasks. this annoys developers who know them out of their head, didn't notice your change and then try to debug something.
also, please try to not export that many new symbols. range reservation and range removal should be enough, the __ symbols aren't even used outside the code, are they?
Quoted 2 lines
Regards,
Krisztian KOVACS
Signature · 5 lines
- Harald Welte <[email protected]> http://www.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
Hi,
Quoted 3 lines · Harald Welte
don't change existing definitions for bits in bitmasks. this annoys developers who know them out of their head, didn't notice your change and then try to debug something.
OK, I'll revert those changes.
Quoted 3 lines
also, please try to not export that many new symbols. range reservation and range removal should be enough, the __ symbols aren't even used outside the code, are they?
Somehow I managed to send the patch which contained some extra exported
functions used by TPROXY. I'll remove them next time.
Signature · 2 lines
Regards,
Krisztian KOVACS