On Mon, Sep 17, 2012 at 9:07 AM, Jan Engelhardt <jengelh@xxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
