On Sat, 2011-05-14 at 14:36 +0100, Ed W wrote: > >> > >> So tcpdump gives me (note sizes are payload, add 28 to compare with conntrack): > >> > >> 22:23:41.014217 IP 10.141.36.76 > 8.8.8.8: ICMP 10.141.36.76 udp port 25630 unreachable, length 214 > >> > >> > > > > Have you tried investigating whether the ICMP packets in question are > > making it into any of the conntrack system? Maybe by using the userspace > > program, or my using the conntrack match extension in iptables? > > I think that these UDP packets are completely missing the entire > conntrack system? > 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. This says to me that conntrack does know about them, but it doesn't do anything with them, as the packets are basically saying "no thanks" to a connection request. I guess you could argue that the packet counters should be updated regardless, although bear in mind that the ICMP packets are related to the original UDP connection, so any update should happen to that connection. You wouldn't see them as a separate connection. > > I am using ulogd2 to dump all the connections and the ones above are all > that I see. Therefore either there is a bug in ulogd2 which isn't > spitting out this connection or conntrack completely misses this packet? > (arguably whether should it be applied to this connection or not mind?) Your last comment there is the key. The ICMP packets are coming in, RELATED to the UDP connection, but are not being applied to it, arguably because of what they are saying. > > I think you are leaning towards confirming this is unexpected and could > be reported as a "bug"? I wouldn't like to say whether it is a bug really... > I wrote up the above on the -devel list but > didn't attract any comments so far It might be worth trying again with a different question, along the lines of "can conntrack be changed to count ICMP unreachable packets related to an existing connection". If you're feeling brave, you could have a poke around in the source code. Andy -- 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
