Le 01/05/2019 à 10:47, Kristian Evensen a écrit : > Hello, > > On Thu, Apr 25, 2019 at 12:07 PM Nicolas Dichtel > <nicolas.dichtel@xxxxxxxxx> wrote: >> Since this patch, there is a regression with 'conntrack -F', it does not flush >> anymore ipv6 conntrack entries. >> In fact, the conntrack tool set by default the family to AF_INET and forbid to >> set the family to something else (the '-f' option is not allowed for the command >> 'flush'). > > I am very sorry for my late reply and for the trouble my change has > caused. However, I am not sure if I agree that it triggers a > regression. Had conntrack for example not set any family and my change > caused only IPv4 entries to be flushed, then I agree it would have > been a regression. If you ask me, what my change has exposed is > incorrect API usage in conntrack. One could argue that since conntrack > explicitly sets the family to AF_INET, the fact that IPv6 entries also > has been flushed has been incorrect. However, if the general consensus > is that this is a regression, I am more than willing to help in > finding a solution (if I have anything to contribute :)). I understand your point, but this is a regression. Ignoring a field/attribute of a netlink message is part of the uAPI. This field exists for more than a decade (probably two), so you cannot just use it because nobody was using it. Just see all discussions about strict validation of netlink messages. Moreover, the conntrack tool exists also for ages and is an official tool. Regards, Nicolas
