netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lutz Jaenicke <ljaenicke@innominate.com>
To: Laszlo Attila Toth <panther@balabit.hu>
Cc: David Miller <davem@davemloft.net>,
	Patrick McHardy <kaber@trash.net>,
	netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
Subject: Re: [PATCHv6 iproute 2/2] Interface group as new ip link option
Date: Fri, 23 Nov 2007 14:25:47 +0100	[thread overview]
Message-ID: <20071123132547.GB31342@innominate.com> (raw)
In-Reply-To: <11955644701808-git-send-email-panther@balabit.hu>

On Tue, Nov 20, 2007 at 02:14:30PM +0100, Laszlo Attila Toth wrote:
> Interfaces can be grouped and each group has an unique positive integer ID.
> It can be set via ip link. Symbolic names can be specified in
> /etc/iproute2/rt_ifgroup.
 
> diff --git a/include/rt_names.h b/include/rt_names.h
> index 07a10e0..72c5247 100644
> --- a/include/rt_names.h
> +++ b/include/rt_names.h
> @@ -8,11 +8,13 @@ char* rtnl_rtscope_n2a(int id, char *buf, int len);
>  char* rtnl_rttable_n2a(__u32 id, char *buf, int len);
>  char* rtnl_rtrealm_n2a(int id, char *buf, int len);
>  char* rtnl_dsfield_n2a(int id, char *buf, int len);
> +char* rtnl_ifgroup_n2a(int id, char *buf, int len);
>  int rtnl_rtprot_a2n(__u32 *id, char *arg);
>  int rtnl_rtscope_a2n(__u32 *id, char *arg);
>  int rtnl_rttable_a2n(__u32 *id, char *arg);
>  int rtnl_rtrealm_a2n(__u32 *id, char *arg);
>  int rtnl_dsfield_a2n(__u32 *id, char *arg);
> +int rtnl_ifgroup_a2n(__u32 *id, char *arg);

Shouldn't rtnl_ifgroup_n2a() using __u32 for "id"? It is actually handed
a __u32 value.

> diff --git a/lib/rt_names.c b/lib/rt_names.c
> index 8d019a0..a067e74 100644
> --- a/lib/rt_names.c
> +++ b/lib/rt_names.c
> @@ -446,3 +446,65 @@ int rtnl_dsfield_a2n(__u32 *id, char *arg)
>  	return 0;
>  }
>  
> +static char * rtnl_rtifgroup_tab[256] = {
> +	"0",
> +};
> +
> +static int rtnl_rtifgroup_init;
> +
> +static void rtnl_rtifgroup_initialize(void)
> +{
> +	rtnl_rtifgroup_init = 1;
> +	rtnl_tab_initialize("/etc/iproute2/rt_ifgroup",
> +			    rtnl_rtifgroup_tab, 256);
> +}
> +
> +char * rtnl_ifgroup_n2a(int id, char *buf, int len)
> +{
> +	if (id<0 || id>=256) {
> +		snprintf(buf, len, "%d", id);
> +		return buf;
> +	}

Shouldn't we better use "hex" here? "hex" is used for values up to 255
and iptables matches use hex for all values as well.
(__u32 change proposed above will make "id<0" pointless.)

> +	if (!rtnl_rtifgroup_tab[id]) {
> +		if (!rtnl_rtifgroup_init)
> +			rtnl_rtifgroup_initialize();
> +	}
> +	if (rtnl_rtifgroup_tab[id])
> +		return rtnl_rtifgroup_tab[id];
> +	snprintf(buf, len, "0x%02x", id);
> +	return buf;
> +}

> +int rtnl_ifgroup_a2n(__u32 *id, char *arg)
> +{
> +	static char *cache = NULL;
> +	static unsigned long res;
> +	char *end;
> +	int i;
> +
> +	if (cache && strcmp(cache, arg) == 0) {
> +		*id = res;
> +		return 0;
> +	}
> +
> +	if (!rtnl_rtifgroup_init)
> +		rtnl_rtifgroup_initialize();
> +
> +	for (i=0; i<256; i++) {
> +		if (rtnl_rtifgroup_tab[i] &&
> +		    strcmp(rtnl_rtifgroup_tab[i], arg) == 0) {
> +			cache = rtnl_rtifgroup_tab[i];
> +			res = i;
> +			*id = res;
> +			return 0;
> +		}
> +	}
> +
> +	res = strtoul(arg, &end, 16);

Why should we hardcode base 16 here. strtoul can handle dec and hex
(0x..) just fine. The iptables matches are usign strtoul(,,0) as
well.

> +	if (!end || end == arg || *end || res > 255)
> +		return -1;

Why do you restrict to values <=255? iptables match does not limit
and I do not really understand why I should restrict the values here.
(Even if they may not have a textual representation.)

Best regards,
	Lutz
-- 
Dr.-Ing. Lutz Jänicke
CTO
Innominate Security Technologies AG  /protecting industrial networks/
tel: +49.30.6392-3308
fax: +49.30.6392-3307
Albert-Einstein-Str. 14
D-12489 Berlin, Germany
www.innominate.com

Register Court: AG Charlottenburg, HR B 81603
Management Board: Joachim Fietz, Dirk Seewald
Chairman of the Supervisory Board: Edward M. Stadum

----------------------------------------------------------------------------

Visit us at the SPS/IPC/Drives in Nuremberg / Germany

27 - 29 November 2007, Hall 9, Stand 9-141

----------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2007-11-23 13:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-20 13:14 [PATCHv6 0/3] Interface group patches Laszlo Attila Toth
2007-11-20 13:14 ` [PATCHv6 1/3] rtnetlink: setlink changes are unprotected; with single notification Laszlo Attila Toth
2007-11-20 13:14   ` [PATCHv6 2/3] Interface group: core (netlink) part Laszlo Attila Toth
2007-11-20 13:14     ` [PATCHv6 3/3] Netfilter Interface group match Laszlo Attila Toth
2007-11-20 13:14       ` [PATCHv6 iptables]Interface " Laszlo Attila Toth
2007-11-20 13:14         ` [PATCHv6 iproute 1/2] Added IFLA_NET_NS_PID as in kernel v2.6.24-rc1 Laszlo Attila Toth
2007-11-20 13:14           ` [PATCHv6 iproute 2/2] Interface group as new ip link option Laszlo Attila Toth
2007-11-23 13:25             ` Lutz Jaenicke [this message]
2007-11-23 13:39         ` [PATCHv6 iptables]Interface group match Lutz Jaenicke
2007-11-29 12:50           ` Laszlo Attila Toth
2007-11-29 16:16             ` Patrick McHardy
2007-11-29 16:23               ` Laszlo Attila Toth
2007-11-29 16:27                 ` Patrick McHardy
2007-11-29 17:14                   ` Jan Engelhardt
2007-11-29 17:15                     ` Patrick McHardy
2007-11-27 13:10       ` [PATCHv6 3/3] Netfilter Interface " Patrick McHardy
2007-11-23 13:18     ` [PATCHv6 2/3] Interface group: core (netlink) part Lutz Jaenicke
2007-11-27 13:07     ` Patrick McHardy
2007-11-27 13:07   ` [PATCHv6 1/3] rtnetlink: setlink changes are unprotected; with single notification Patrick McHardy
2007-11-20 13:26 ` [PATCHv6 0/3] Interface group patches Jan Engelhardt
2007-11-20 13:52   ` Laszlo Attila Toth
2007-11-20 21:42     ` David Miller
2007-11-21  0:25       ` Patrick McHardy
2007-11-21  1:17         ` David Miller
2007-11-22  9:05           ` Laszlo Attila Toth
2007-11-21 15:56         ` Balazs Scheidler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071123132547.GB31342@innominate.com \
    --to=ljaenicke@innominate.com \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=panther@balabit.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).