Re: Possible conntrack/kernel bug - not catching certain ICMP packets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26.07.2011 01:45, Jan Engelhardt wrote:
> 
> On Thursday 2011-07-21 11:14, Patrick McHardy wrote:
>> On 21.07.2011 10:43, Ed W wrote:
>>> On 21/07/2011 07:16, Patrick McHardy wrote:
>>>> It's expected behaviour since ICMP packets related to an existing
>>>> connection don't refresh the connection and are not accounted.
>>>> I don't have an opinion on whether they should be accounted, I
>>>> guess you could argue both ways.
>>>
>>> Thanks for the feedback.
>>>
>>> I guess I was hoping that conntrack could be used for accurate bandwidth
>>> accounting, however, it seems to ignore this type of packet, so it's
>>> count is going to deviate from a simple interface byte counter?
>>
>> Yes, but it's going to do that anyways since there are also packets
>> which can't be tracked, invalid packets, etc. Also conntrack doesn't
>> account for link layer headers and only for IPv4/v6 packets.
> 
> While toying around, I found that if an skb is classified as RELATED,
> skb->nfct->master always points to skb->nfct itself. Is that a bug
> or something? Should it not point to the origin CT?

For RELATED connections expected by a helper? That would be wrong, it
should point to the real master.
--
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


[Index of Archives]     [Netfitler Users]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux