Re: [ipset] hash:net,iface bug?
On Mon, 23 May 2016, Jozsef Kadlecsik wrote: > On Mon, 23 May 2016, Marek Mrva wrote: > > > I have been playing with hash:net,iface table for a couple of days now, > > but for the love of me, I can't make it accept physdev: devices. > > > > The man says: When the interface is flagged with physdev:, the interface > > is interpreted as the incoming/outgoing bridge port. [...] > > The IPSET_FLAG_PHYSDEV is passed from userspace, of course, see > ipset_parse_iface() in lib/parse.c. However, it seems it is not stored > when the user input in processed in the kernel. I'll double check and fix > it. Digging into the code further, the IPSET_FLAG_PHYSDEV is stored in the kernel in the hash data. However, the logic to test it is broken. The current code in the kernel assumes that the "set" match has got a flag like "--match--physdev", however there is no such a flag. The problem is that we may store in a hash:net,iface type of set both or either of 10.0.0.0/24,eth0 10.0.0.0/24,physdev:eth0 So we have to tell to the "set" match which one we want to match. I'm going to add the flag "--match--physdev" to the "set" match in a new revision. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ipset] hash:net,iface bug?
On Mon, 23 May 2016, Marek Mrva wrote:
> I have been playing with hash:net,iface table for a couple of days now,
> but for the love of me, I can't make it accept physdev: devices.
>
> The man says: When the interface is flagged with physdev:, the interface
> is interpreted as the incoming/outgoing bridge port.
>
> It all boils down to this code (for IPv4):
>
> --- kernel/net/netfilter/ipset/ip_set_hash_netiface.c@154, ipset repository
> ---
>
> static int
> hash_netiface4_kadt(struct ip_set *set, const struct sk_buff *skb,
> const struct xt_action_param *par,
> enum ipset_adt adt, struct ip_set_adt_opt *opt)
> {
> --- snip ---
> if (opt->cmdflags & IPSET_FLAG_PHYSDEV) {
> #if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
> const char *eiface = SRCDIR ? get_physindev_name(skb) :
> get_physoutdev_name(skb);
>
> if (!eiface)
> return -EINVAL;
> STRLCPY(e.iface, eiface);
> e.physdev = 1;
> #endif
> } else {
> STRLCPY(e.iface, SRCDIR ? IFACE(in) : IFACE(out));
> }
> --- snip ---
> }
>
> The IPSET_FLAG_PHYSDEV (value 2) is never set, nor could I find any
> useful references to it (I tried really hard). I believe this code never
> obtains the "physical" (bridge) port. opt->cmdflags (probably?) contains
> flags passed to ipset code by iptables. I've seen these values used:
>
> 1 -j SET --exists
> 8 -m set ! --update-counters
> 16-m set ! --update-subcounters
> 32-m set --bytes-lt (or any other combination of bytes/packets)
> 128 -m set --return-nomatch
>
> The table resembling it most closely is this one:
>
> --- include/libipset/linux_ip_set.h@159, ipset repository ---
>
> /* Flags at command level or match/target flags, lower half of cmdattrs*/
> enum ipset_cmd_flags {
> IPSET_FLAG_BIT_EXIST= 0,
> IPSET_FLAG_EXIST= (1 << IPSET_FLAG_BIT_EXIST),
> IPSET_FLAG_BIT_LIST_SETNAME = 1,
> IPSET_FLAG_LIST_SETNAME = (1 << IPSET_FLAG_BIT_LIST_SETNAME),
> IPSET_FLAG_BIT_LIST_HEADER = 2,
> IPSET_FLAG_LIST_HEADER = (1 << IPSET_FLAG_BIT_LIST_HEADER),
> IPSET_FLAG_BIT_SKIP_COUNTER_UPDATE = 3,
> IPSET_FLAG_SKIP_COUNTER_UPDATE =
> (1 << IPSET_FLAG_BIT_SKIP_COUNTER_UPDATE),
> IPSET_FLAG_BIT_SKIP_SUBCOUNTER_UPDATE = 4,
> IPSET_FLAG_SKIP_SUBCOUNTER_UPDATE =
> (1 << IPSET_FLAG_BIT_SKIP_SUBCOUNTER_UPDATE),
> IPSET_FLAG_BIT_MATCH_COUNTERS = 5,
> IPSET_FLAG_MATCH_COUNTERS = (1 << IPSET_FLAG_BIT_MATCH_COUNTERS),
> IPSET_FLAG_BIT_RETURN_NOMATCH = 7,
> IPSET_FLAG_RETURN_NOMATCH = (1 << IPSET_FLAG_BIT_RETURN_NOMATCH),
> IPSET_FLAG_BIT_MAP_SKBMARK = 8,
> IPSET_FLAG_MAP_SKBMARK = (1 << IPSET_FLAG_BIT_MAP_SKBMARK),
> IPSET_FLAG_BIT_MAP_SKBPRIO = 9,
> IPSET_FLAG_MAP_SKBPRIO = (1 << IPSET_FLAG_BIT_MAP_SKBPRIO),
> IPSET_FLAG_BIT_MAP_SKBQUEUE = 10,
> IPSET_FLAG_MAP_SKBQUEUE = (1 << IPSET_FLAG_BIT_MAP_SKBQUEUE),
> IPSET_FLAG_CMD_MAX = 15,
> };
>
> If that is correct, the IPSET_FLAG_LIST_SETNAME should be responsible
> for using PHYSDEV. I tried searching for this flag, but was unable to
> find a place where it is set.
>
> Any ideas on this are very welcome :)
The IPSET_FLAG_PHYSDEV is passed from userspace, of course, see
ipset_parse_iface() in lib/parse.c. However, it seems it is not stored
when the user input in processed in the kernel. I'll double check and fix
it.
Best regards,
Jozsef
-
E-mail : kad...@blackhole.kfki.hu, kadlecsik.joz...@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ipset] hash:net,iface bug?
Hi guys,
I have been playing with hash:net,iface table for a couple of days now, but for
the love of me, I can't make it accept physdev: devices.
The man says:
When the interface is flagged with physdev:, the interface is interpreted
as the incoming/outgoing bridge port.
It all boils down to this code (for IPv4):
--- kernel/net/netfilter/ipset/ip_set_hash_netiface.c@154, ipset repository ---
static int
hash_netiface4_kadt(struct ip_set *set, const struct sk_buff *skb,
const struct xt_action_param *par,
enum ipset_adt adt, struct ip_set_adt_opt *opt)
{
--- snip ---
if (opt->cmdflags & IPSET_FLAG_PHYSDEV) {
#if IS_ENABLED(CONFIG_BRIDGE_NETFILTER)
const char *eiface = SRCDIR ? get_physindev_name(skb) :
get_physoutdev_name(skb);
if (!eiface)
return -EINVAL;
STRLCPY(e.iface, eiface);
e.physdev = 1;
#endif
} else {
STRLCPY(e.iface, SRCDIR ? IFACE(in) : IFACE(out));
}
--- snip ---
}
The IPSET_FLAG_PHYSDEV (value 2) is never set, nor could I find any useful
references to it (I tried really hard). I believe this code never obtains the
"physical" (bridge) port.
opt->cmdflags (probably?) contains flags passed to ipset code by iptables. I've
seen these values used:
1 -j SET --exists
8 -m set ! --update-counters
16 -m set ! --update-subcounters
32 -m set --bytes-lt (or any other combination of bytes/packets)
128 -m set --return-nomatch
The table resembling it most closely is this one:
--- include/libipset/linux_ip_set.h@159, ipset repository ---
/* Flags at command level or match/target flags, lower half of cmdattrs*/
enum ipset_cmd_flags {
IPSET_FLAG_BIT_EXIST= 0,
IPSET_FLAG_EXIST= (1 << IPSET_FLAG_BIT_EXIST),
IPSET_FLAG_BIT_LIST_SETNAME = 1,
IPSET_FLAG_LIST_SETNAME = (1 << IPSET_FLAG_BIT_LIST_SETNAME),
IPSET_FLAG_BIT_LIST_HEADER = 2,
IPSET_FLAG_LIST_HEADER = (1 << IPSET_FLAG_BIT_LIST_HEADER),
IPSET_FLAG_BIT_SKIP_COUNTER_UPDATE = 3,
IPSET_FLAG_SKIP_COUNTER_UPDATE =
(1 << IPSET_FLAG_BIT_SKIP_COUNTER_UPDATE),
IPSET_FLAG_BIT_SKIP_SUBCOUNTER_UPDATE = 4,
IPSET_FLAG_SKIP_SUBCOUNTER_UPDATE =
(1 << IPSET_FLAG_BIT_SKIP_SUBCOUNTER_UPDATE),
IPSET_FLAG_BIT_MATCH_COUNTERS = 5,
IPSET_FLAG_MATCH_COUNTERS = (1 << IPSET_FLAG_BIT_MATCH_COUNTERS),
IPSET_FLAG_BIT_RETURN_NOMATCH = 7,
IPSET_FLAG_RETURN_NOMATCH = (1 << IPSET_FLAG_BIT_RETURN_NOMATCH),
IPSET_FLAG_BIT_MAP_SKBMARK = 8,
IPSET_FLAG_MAP_SKBMARK = (1 << IPSET_FLAG_BIT_MAP_SKBMARK),
IPSET_FLAG_BIT_MAP_SKBPRIO = 9,
IPSET_FLAG_MAP_SKBPRIO = (1 << IPSET_FLAG_BIT_MAP_SKBPRIO),
IPSET_FLAG_BIT_MAP_SKBQUEUE = 10,
IPSET_FLAG_MAP_SKBQUEUE = (1 << IPSET_FLAG_BIT_MAP_SKBQUEUE),
IPSET_FLAG_CMD_MAX = 15,
};
If that is correct, the IPSET_FLAG_LIST_SETNAME should be responsible for using
PHYSDEV. I tried searching for this flag, but was unable to find a place where
it is set.
Any ideas on this are very welcome :)
M.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
