> Yes. The packets are tossed because the conntrack they're associated > with is unconfirmed, and on reinject they clash with the unconfirmed > ct of the 1st packet that has been inserted into the conntrack table. Is there a way it can be worked around other than queueing in the raw table? This isn't suitable for me as I want to check the connmark to tell if packets in a given stream should be queued. I've been trying to follow the code involved and I don't understand what purpose the confirmed flag serves. Why is adding to the conntrack table saved until the very end of netfilter processing and why does nf_conntrack_confirm have to drop packets when an entry already exists in the table rather than using it? Thanks -- Daniel Collins Junior Developer daniel.collins@xxxxxxxxxxxxxx Smoothwall Ltd Phone: +44 (0) 8701 999500 www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247 and whose registered address is 1 John Charles Way, Leeds, LS12 6QA United Kingdom Any opinions stated in this message are solely those of the author. -- 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
