Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > Listening to the conntrack events this does not happen, as you get the NEW event > > only after the ct is confirmed, but unfortunately you get the packet from queue > > and the log messages well before that. > > ct->ext also might change while packet is in transit, since new > extension can be added too. Not after confirmation though. > &ct->tuplehash was not good either for event retransmission, since > hnnode might change (when moving the object to the dying list), so > ct->tuplehash[x].tuple looks good to me. Oh, thats a fair point (dying list), had not considered that. So this needs fixing in any case. > @Florian: by mangling this patch not to use ct->ext, including Dirk's > update, conntrackd works again (remember that bug we discussed during > NFWS). But conntrackd is still borken. It can't rely on id recycling -- it will just take a lot longer before it starts to fill up. > @@ -470,8 +470,8 @@ u32 nf_ct_get_id(const struct nf_conn *ct) > > a = (unsigned long)ct; > b = (unsigned long)ct->master ^ net_hash_mix(nf_ct_net(ct)); > - c = (unsigned long)ct->ext; > - d = (unsigned long)siphash(&ct->tuplehash[IP_CT_DIR_ORIGINAL], sizeof(ct->tuplehash[IP_CT_DIR_ORIGINAL]), > + c = (unsigned long)0; > + d = (unsigned long)siphash(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, sizeof(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); > I think it's safe to turn this into: > > a = (unsigned long)ct; > b = (unsigned long)ct->master; > c = (unsigned long)nf_ct_net(ct)); > d = (unsigned long)siphash(&ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, sizeof(ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); No, not if we allow using the function before confirmation, the tuple can also change in original dir when e.g. queuing before NAT hooks.
