On Sunday 2011-05-15 09:23, Andrew Beverley wrote: >On Sun, 2011-05-15 at 00:33 +0200, Jan Engelhardt wrote: >> On Saturday 2011-05-14 18:29, Andrew Beverley wrote: >> >> >On Sat, 2011-05-14 at 14:36 +0100, Ed W wrote: >> > >> >Okay, I've played around with this myself using a similar scenario. It >> >looks to me like the packets *are* making it into the conntrack system. >> > >> >I tried setting a LOG target to match those packets with a ctstate of >> >RELATED: >> > >> >iptables -A INPUT -p ICMP -m conntrack --ctstate RELATED -j LOG >> > >> >And they were indeed logged. But there was no visibility of them using >> >the conntrack userspace program. >> >> Does `conntrack -L` show anything for you at all? > >Yes, it shows the outgoing packets: > >udp 17 23 src=10.0.10.206 dst=212.110.185.119 sport=35259 dport=53 >packets=3 bytes=168 [UNREPLIED] src=212.110.185.119 dst=10.0.10.206 >sport=53 dport=35259 packets=0 bytes=0 mark=0 secmark=0 use=2 > >But it doesn't show the "ICMP port unreachable" packets that are sent in >reply. The question is: should it show them? conntrack -L shows pseudo/NFCT-style connections, not packets. As for ICMP port unreachable, either its classification is - INVALID, in which case there is no CT to show - a reply, in which case it is part of the shown CT - and the event monitor will show an UPDATE - RELATED, in which case a new CT is shown - and which may disappear shortly after due to a short lifetime - the event monitor should show NEW I think. Monitor with conntrack -E for details. >> There is/was a >> short intermediate time when it would not return anything. > >Do you mean there was a time when a particular version of conntrack >would not return anything? Yes, see kernel commit cba85b532e4aabdb97f44c18987d45141fd93faa that (the fix) for details. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
