static bool led_tg_check(const struct xt_tgchk_param *par)
{
struct xt_led_info *ledinfo = par->targinfo;
- struct xt_led_info_internal *ledinternal;
+ struct xt_led_info_internal *ledinternal = ledinfo->internal_data;
int err;
You cannot rely on ledinfo->internal_data having any meaningful
value when iptables prepares the rule.
Hmm ok, so in led_tg_check (the .checkentry function) how do you tell whether
the xt_tgchk_param is pointing to an existing ruleset or not? Or is it always
referring to a new ruleset and you have to handle it yourself?
I guess my question comes from this point of view:
$ iptables -A scroll_lock -j LED --led-trigger-id http
This calls led_tg_check() with a new xt_tgchk_param structure.
$ iptables -I INPUT 1 -p tcp --sport 80 -j scroll_lock
Now led_tg_check() gets called again with an xt_tgchk_param structure
containing the trigger name etc. even though this was not specified on the
command line. Where does that second xt_tgchk_param come from if it's not a
pointer to the first one?
Thanks,
Adam.
--
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
