[PATCH iptables] libxtables: Call ipaddr_to_network before ipaddr_to_host.

[PATCH iptables] libxtables: Call ipaddr_to_network before ipaddr_to_host.

[Hani Benhabiles]

Call ipaddr_to_network before ipaddr_to_host.

This saves waiting for a reverse DNS lookup query when the entry is present in
/etc/networks. This also follows the same order as in rules creation.

Signed-off-by: Hani Benhabiles <kroosec@gmail.com>
---
 libxtables/xtables.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libxtables/xtables.c b/libxtables/xtables.c
index fb60c01..bb25262 100644
--- a/libxtables/xtables.c
+++ b/libxtables/xtables.c
@@ -1207,8 +1207,8 @@ const char *xtables_ipaddr_to_anyname(const struct in_addr *addr)
 {
 	const char *name;
 
-	if ((name = ipaddr_to_host(addr)) != NULL ||
-	    (name = ipaddr_to_network(addr)) != NULL)
+	if ((name = ipaddr_to_network(addr)) != NULL ||
+	    (name = ipaddr_to_host(addr)) != NULL)
 		return name;
 
 	return xtables_ipaddr_to_numeric(addr);
-- 
1.8.3.2

Re: [PATCH iptables] libxtables: Call ipaddr_to_network before ipaddr_to_host.

[Pablo Neira Ayuso]

On Mon, Dec 09, 2013 at 09:02:23PM +0100, Hani Benhabiles wrote:
> Call ipaddr_to_network before ipaddr_to_host.
> 
> This saves waiting for a reverse DNS lookup query when the entry is present in
> /etc/networks. This also follows the same order as in rules creation.

This saves time and it makes sense to me to check local file before
name resolution via network, but...

> Signed-off-by: Hani Benhabiles <kroosec@gmail.com>
> ---
>  libxtables/xtables.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libxtables/xtables.c b/libxtables/xtables.c
> index fb60c01..bb25262 100644
> --- a/libxtables/xtables.c
> +++ b/libxtables/xtables.c
> @@ -1207,8 +1207,8 @@ const char *xtables_ipaddr_to_anyname(const struct in_addr *addr)
>  {
>  	const char *name;
>  
> -	if ((name = ipaddr_to_host(addr)) != NULL ||
> -	    (name = ipaddr_to_network(addr)) != NULL)
> +	if ((name = ipaddr_to_network(addr)) != NULL ||
> +	    (name = ipaddr_to_host(addr)) != NULL)

My only concern is the remote case in which you may have a network
name that overlaps with some existing host name, in that case the
expected output different.

Re: [PATCH iptables] libxtables: Call ipaddr_to_network before ipaddr_to_host.

[Hani Benhabiles]

Hi Pablo,

On Mon, Dec 30, 2013 at 06:46:03PM +0100, Pablo Neira Ayuso wrote:
> On Mon, Dec 09, 2013 at 09:02:23PM +0100, Hani Benhabiles wrote:
> > Call ipaddr_to_network before ipaddr_to_host.
> > 
> > This saves waiting for a reverse DNS lookup query when the entry is present in
> > /etc/networks. This also follows the same order as in rules creation.
> 
> This saves time and it makes sense to me to check local file before
> name resolution via network, but...
> 
> > Signed-off-by: Hani Benhabiles <kroosec@gmail.com>
> > ---
> >  libxtables/xtables.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libxtables/xtables.c b/libxtables/xtables.c
> > index fb60c01..bb25262 100644
> > --- a/libxtables/xtables.c
> > +++ b/libxtables/xtables.c
> > @@ -1207,8 +1207,8 @@ const char *xtables_ipaddr_to_anyname(const struct in_addr *addr)
> >  {
> >  	const char *name;
> >  
> > -	if ((name = ipaddr_to_host(addr)) != NULL ||
> > -	    (name = ipaddr_to_network(addr)) != NULL)
> > +	if ((name = ipaddr_to_network(addr)) != NULL ||
> > +	    (name = ipaddr_to_host(addr)) != NULL)
> 
> My only concern is the remote case in which you may have a network
> name that overlaps with some existing host name, in that case the
> expected output different.
> 

This is already the case in rules creation. In xtables.c:ipparse_hostnetwork()
we have network_to_ipaddr() call prior to host_to_ipaddr().

I believe that a consistent behaviour for users is important ie. either network
names or host names should come first in both resolving and reverse resolving.

Maybe be consistent, and make host names a priority in rules creation, then ?
However, I believe networks should come first, mainly due to the potential
time/bandwidth save.

Regards,

Hani.