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
next prev parent 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).