Hi! (I've now subscribed to netdev@, so no more CCs to me are necessary). On Tue, 27 Jan 2009, Patrick McHardy wrote: > That sounds plausible, but we only discard the new conntrack > entry on clashes. The packet should be fine, unless you drop > INVALID packets in your ruleset. The ruleset currently does not contain any rules regarding INVALID. Consequently, we opted for the TRACE approach. > Try tracing the packet using the TRACE target. That should show > whether it really disappears within netfilter and where. I've removed the irrelevant fields like TTL, PREC etc and timing info from syslog from the trace after making sure nothing funky was going on there. Apart from the ID field, I ended up with two identical traces. So, as far as rule-matching is concerned, the two packets are handled identically. Whatever happens after this: Jan 27 11:00:39 fw2 kernel: TRACE: nat:POSTROUTING:policy:3 IN= OUT=eth2.188 SRC=194.97.7.116 DST=194.97.3.83 LEN=66 TOS=0x00 PREC=0x00 TTL=63 ID=46964 DF PROTO=UDP SPT=53452 DPT=53 LEN=46 is making this very packet go away. The policy of nat/PR is ACCEPT. Presuming this: http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png is accurate, I'm not sure what could drop the packet. We're not using QoS or tunneling on the packetfilter in question. This happens on two different machines (the machines are of the same type, but they have different NICs), so I doubt it's a hardware or driver issue. -- printk("Cool stuff's happening!\n") linux-2.4.3/fs/jffs/intrep.c -- 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
