Re: [PATCH 1/4] Fix expectaction mask dumping, take #3

[Pablo Neira Ayuso <pablo@netfilter.org>]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
> 
>>>Besides, this modification introduces the attribute CTA_IP_L3NUM.
>>>Although the layer 3 protocol information is sent in the nfnetlink
>>>header, if the message contains information about an expectation, it
>>>will contain information about the master conntrack (just one of the
>>>tuples), the expectation tuple and the expectation mask. In this case,
>>>the value of l3num in the expectation mask is not the same that is set
>>>in the nfnetlink message. That is why we need another field that contain
>>>the value of l3num.
>>
>>I'm not sure I understand. The new attribute still contains the same
>>value as the netlink header, doesn't it? So userspace should currently
>>have at least two possibilities to get the correct value:
>>
>>- use the value from the netlink header
>>- use the value from the tuple that comes with the mask, as the first
>>  part of your patch does. This seems most logically to me since the
>>  mask and the tuple belong together.
> 
> The problem is that currently the expectation mask is not dumped.
> find_l3proto returns the generic protocol handler for 0xFF, and that
> doesn't dump any layer 3 information. Moreover, the expectation mask has
> l3num value that is different from the l3num in the nfnetlink header,
> that's why I introduced this field.
> 
> I can send a patch to remove the expectation mask dumping but I'm not
> sure if this information could be useful for userspace helpers. Harald?

I think I can answer myself after some thinking: in order to create an
expectation from userspace we will need to set the value of l3num of the
expectation mask. Such value will be different from the value in the
nfnetlink header, so I still think that we need that new CTA_L3NUM
attribute.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris