Jan Engelhardt wrote:
On Tuesday 2008-03-25 15:14, Patrick McHardy wrote:
/****************************************************************************/
+static const struct nf_conntrack_expect_policy h245_exp_policy = {
+ .max_expected = H323_RTP_CHANNEL_MAX * 4 + 2 /* T.120 */,
+ .timeout = 240,
+};
+
Developer questions: what does ->max_expected limit?
Expectations for one connection, or for the whole helper module?
Unfulfilled expectations per conntrack.
@@ -110,7 +110,8 @@ int nf_conntrack_helper_register(struct
nf_conntrack_helper *me)
{
unsigned int h = helper_hash(&me->tuple);
- BUG_ON(me->timeout == 0);
+ BUG_ON(me->expect_policy == NULL);
+ BUG_ON(me->expect_class_max >= NF_CT_MAX_EXPECT_CLASSES);
mutex_lock(&nf_ct_helper_mutex);
hlist_add_head_rcu(&me->hnode, &nf_ct_helper_hash[h]);
A zero timeout triggered a BUG_ON in nf_conntrack_helper_register,
now this check is gone!?
Yes, it requires iterating through the policies,
which is too much trouble for checking a developer
bug (and no module in the kernel does this). In fact
the SNMP NAT helper sets a fake timeout to avoid
triggering the BUG_ON since it never registers any
expectations.
--
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
