Help parsing options with iptables extension

Help parsing options with iptables extension

[Aft nix]

Hi,
It seems writing actual kernel module is easier then writing its
iptables counterpart :)

I'm trying to write a userspace plugin for my in kernel netfilter module.

Data structure i'm trying to populate is following :

#define XT_OBSF_MAX_KEY_LEN 32
enum {
	XT_OBSF_ENC_ARC4 = 1 << 0,
	XT_OBSF_ENC_AES = 1 << 1,
	XT_OBSF_PAD_STATIC = 1 << 2,
	XT_OBSF_PAD_RANDOM = 1 << 3,
	XT_OBSF_ENC_ENC = 1 << 4,
	XT_OBSF_ENC_DEC = 1 << 5,
	XT_OBSF_PAD_ADD = 1 << 6,
	XT_OBSF_PAD_REM = 1 << 7
};

struct enc_info {
		__u8 key[XT_OBSF_MAX_KEY_LEN];
		__u8 kl;
	};

struct pad_info {
		__u8 s;
		__u8 e;
	};

struct xt_OBSF_tginfo {
	__u8 flags;
	struct enc_info *e_info;
	struct xt_obsf_priv *priv;
};

struct xt_OBSF_tginfo_v1 {
	__u8 flags;
	struct enc_info *e_info;
	struct pad_info *p_info;
	struct xt_obsf_priv *priv;
};

The structure of options are :

static void OBSF_help(void)
{
	printf(
		"OBSF target obtions\n"
		"  --key key --keylen kln "
			"key is <32 byte valued"
                    --enc-type aes/arc4

		""
		);
}

static void OBSF_help_v1(void)
{
	OBSF_help();
	printf(
		"  --pad yes/no --pad-type static/random --s start value ---e end value"
				"start/end value 0-255"
				"start > end"
		""
		);
}

What i'm trying to do is following:

struct xt_OBSF_info * info;

--key "key" will go into              info->e_info->key
--keylen "len" will go into          info->e_info->kl
--enc-type static/random will set flag in info->flags

--pad if its present then      struct xt_OBSF_info_v1        will be used.
--pad-type static/random will set flag into info->flags
--s "start_value" and --e "end_value" will go info info->p_info->s and
info->p_info->e

Now i'm confused how i should initialize

struct xt_option_entry OBSF_opts[] = {

......
......
......

}

I've seen the example for xt_NFQUEUE.c and tried to model my
initialization after it, but
its a little confusing.

Thanks in advance.
-aft

Re: Help parsing options with iptables extension

[Jan Engelhardt]

On Saturday 2012-09-15 12:58, Aft nix wrote:
>
>struct enc_info {
>		__u8 key[XT_OBSF_MAX_KEY_LEN];
>		__u8 kl;
>	};
>
>struct pad_info {
>		__u8 s;
>		__u8 e;
>	};

Meaningful member names and a description à la kerneldoc would
help here understanding what these are actually for..
(like, which is to be filled with XT_OBSF_ values)

>
>struct xt_OBSF_tginfo {
>	__u8 flags;
>	struct enc_info *e_info;
>	struct xt_obsf_priv *priv;
>};

You must not use pointers in general. When retrieving the ruleset
from the kernel, they will not have any sensible value. While that
is ok for kernel-private fields like "priv" here, it's not for
e_info and p_info which you will likely want to dump in userspace.

>struct xt_OBSF_tginfo_v1 {
>	__u8 flags;
>	struct enc_info *e_info;
>	struct pad_info *p_info;
>	struct xt_obsf_priv *priv;
>};
>
>What i'm trying to do is following:
>
>struct xt_OBSF_info * info;
>
>--key "key" will go into              info->e_info->key
>--keylen "len" will go into          info->e_info->kl
>--enc-type static/random will set flag in info->flags
>
>--pad if its present then      struct xt_OBSF_info_v1        will be used.
>--pad-type static/random will set flag into info->flags
>--s "start_value" and --e "end_value" will go info info->p_info->s and
>info->p_info->e
>
>Now i'm confused how i should initialize
>
Barring what I said above about e_info and p_info,

enum {
	O_OBSF_KEY,
	O_OBSF_KEYLEN,
};
enum { /* only if needed */
	F_OBSF_KEY = 1 << O_OBSF_KEY,
	...
};
struct xt_option_entry OBSF_opts[] = {
	{.name = "key", .id = O_OBSF_KEY, .type = XTTYPE_STRING,
	 .flags = XTOPT_PUT, XTOPT_POINTER(struct enc_info, key)},

	--keylen is redundant, because you can devise that from the key itself

	{.name = "enc-type", .id = O_OBSF_ENC_TYPE, .type = XTTYPE_STRING},
	XTOPT_TABLEEND,
};

static int parse(struct xt_option_call *cb)
{
	struct xt_OBSF_v1 *info = cb->data;

	xtables_option_parse(cb);
	switch (cb->entry->id) {
	case O_OBSF_KEY:
		info->e_info->keylen = strlen(info->e_info->key);
		break;
	case O_OBSF_ENC_TYPE:
		if (strcmp(cb->arg, "static") == 0)
			info->flags |= ...
		else if (strcmp(cb->arg, "random") == 0)
			...
		break;
	...
	}
}

>I've seen the example for xt_NFQUEUE.c and tried to model my
>initialization after it, but
>its a little confusing.

The getopt structure facilitates placing the values for certain
options (of certain types, like uint32, etc.) directly into the
info without requiring parse code.
For things like --enc-type which go beyond generic "put a into b"
you need manual code, done in said parse function.
--
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

Re: Help parsing options with iptables extension

[Aft nix]

On Mon, Sep 17, 2012 at 9:07 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Saturday 2012-09-15 12:58, Aft nix wrote:
>>
>>struct enc_info {
>>               __u8 key[XT_OBSF_MAX_KEY_LEN];
>>               __u8 kl;
>>       };
>>
>>struct pad_info {
>>               __u8 s;
>>               __u8 e;
>>       };
>
> Meaningful member names and a description à la kerneldoc would
> help here understanding what these are actually for..
> (like, which is to be filled with XT_OBSF_ values)
>
>>
>>struct xt_OBSF_tginfo {
>>       __u8 flags;
>>       struct enc_info *e_info;
>>       struct xt_obsf_priv *priv;
>>};
>
> You must not use pointers in general. When retrieving the ruleset
> from the kernel, they will not have any sensible value. While that
> is ok for kernel-private fields like "priv" here, it's not for
> e_info and p_info which you will likely want to dump in userspace.
>
>>struct xt_OBSF_tginfo_v1 {
>>       __u8 flags;
>>       struct enc_info *e_info;
>>       struct pad_info *p_info;
>>       struct xt_obsf_priv *priv;
>>};
>>
>>What i'm trying to do is following:
>>
>>struct xt_OBSF_info * info;
>>
>>--key "key" will go into              info->e_info->key
>>--keylen "len" will go into          info->e_info->kl
>>--enc-type static/random will set flag in info->flags
>>
>>--pad if its present then      struct xt_OBSF_info_v1        will be used.
>>--pad-type static/random will set flag into info->flags
>>--s "start_value" and --e "end_value" will go info info->p_info->s and
>>info->p_info->e
>>
>>Now i'm confused how i should initialize
>>
> Barring what I said above about e_info and p_info,
>
> enum {
>         O_OBSF_KEY,
>         O_OBSF_KEYLEN,
> };
> enum { /* only if needed */
>         F_OBSF_KEY = 1 << O_OBSF_KEY,
>         ...
> };
> struct xt_option_entry OBSF_opts[] = {
>         {.name = "key", .id = O_OBSF_KEY, .type = XTTYPE_STRING,
>          .flags = XTOPT_PUT, XTOPT_POINTER(struct enc_info, key)},
>
>         --keylen is redundant, because you can devise that from the key itself
>
>         {.name = "enc-type", .id = O_OBSF_ENC_TYPE, .type = XTTYPE_STRING},
>         XTOPT_TABLEEND,
> };
>
> static int parse(struct xt_option_call *cb)
> {
>         struct xt_OBSF_v1 *info = cb->data;
>
>         xtables_option_parse(cb);
>         switch (cb->entry->id) {
>         case O_OBSF_KEY:
>                 info->e_info->keylen = strlen(info->e_info->key);
>                 break;
>         case O_OBSF_ENC_TYPE:
>                 if (strcmp(cb->arg, "static") == 0)
>                         info->flags |= ...
>                 else if (strcmp(cb->arg, "random") == 0)
>                         ...
>                 break;
>         ...
>         }
> }
>
>>I've seen the example for xt_NFQUEUE.c and tried to model my
>>initialization after it, but
>>its a little confusing.
>
> The getopt structure facilitates placing the values for certain
> options (of certain types, like uint32, etc.) directly into the
> info without requiring parse code.
> For things like --enc-type which go beyond generic "put a into b"
> you need manual code, done in said parse function.


Thanks for detailed explanation. I will try stuff this way and will
get back with further code.(In between, when the module
is finished, given that its not a generic enough use case, will the
module will be accepted in xtables-addons(I'm actually
counting on the reviews by experts like you)?

-- 
-aft
--
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

Re: Help parsing options with iptables extension

[Jan Engelhardt]

On Monday 2012-09-17 11:23, Aft nix wrote:
>
>Thanks for detailed explanation. I will try stuff this way and will
>get back with further code.(In between, when the module
>is finished, given that its not a generic enough use case, will the
>module will be accepted in xtables-addons(I'm actually
>counting on the reviews by experts like you)?

Well, you should post early, and in small logical self-contained bites.

Start before it is finished.

Re: Help parsing options with iptables extension

[Aft nix]

On Mon, Sep 17, 2012 at 4:11 PM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Monday 2012-09-17 11:23, Aft nix wrote:
>>
>>Thanks for detailed explanation. I will try stuff this way and will
>>get back with further code.(In between, when the module
>>is finished, given that its not a generic enough use case, will the
>>module will be accepted in xtables-addons(I'm actually
>>counting on the reviews by experts like you)?
>
> Well, you should post early, and in small logical self-contained bites.
>
> Start before it is finished.

Should i post it in PATCH form? Like my xt_OBSF.c is now built
ok(haven't tested it because libxt_OBSF.c is not ready). So may be
should post xt_OBSF.c/xt_OBSF.h in PATCH?


-- 
-aft

Re: Help parsing options with iptables extension

[Jan Engelhardt]

On Monday 2012-09-17 12:17, Aft nix wrote:

>On Mon, Sep 17, 2012 at 4:11 PM, Jan Engelhardt <jengelh@inai.de> wrote:
>>
>> On Monday 2012-09-17 11:23, Aft nix wrote:
>>>
>>>Thanks for detailed explanation. I will try stuff this way and will
>>>get back with further code.(In between, when the module
>>>is finished, given that its not a generic enough use case, will the
>>>module will be accepted in xtables-addons(I'm actually
>>>counting on the reviews by experts like you)?
>>
>> Well, you should post early, and in small logical self-contained bites.
>>
>> Start before it is finished.
>
>Should i post it in PATCH form?

What else is there that does not require more than just a mail client
to make a reply? :)

Re: Help parsing options with iptables extension

[Aft nix]

On Mon, Sep 17, 2012 at 4:21 PM, Jan Engelhardt <jengelh@inai.de> wrote:
> On Monday 2012-09-17 12:17, Aft nix wrote:
>
>>On Mon, Sep 17, 2012 at 4:11 PM, Jan Engelhardt <jengelh@inai.de> wrote:
>>>
>>> On Monday 2012-09-17 11:23, Aft nix wrote:
>>>>
>>>>Thanks for detailed explanation. I will try stuff this way and will
>>>>get back with further code.(In between, when the module
>>>>is finished, given that its not a generic enough use case, will the
>>>>module will be accepted in xtables-addons(I'm actually
>>>>counting on the reviews by experts like you)?
>>>
>>> Well, you should post early, and in small logical self-contained bites.
>>>
>>> Start before it is finished.
>>
>>Should i post it in PATCH form?
>
> What else is there that does not require more than just a mail client
> to make a reply? :)

Thanks. I will do that...

cheers.


-- 
-aft