Re: [PATCH] CTA_PROTO_NUM is u_int8_t not u_int16_t (was Re: CTA_PROTO_NUM u_int8_t or u_int16_t)

[Pablo Neira Ayuso <pablo@eurodev.net>]

Patrick McHardy wrote:
> Krzysztof Oledzki wrote:
>>
>> On Fri, 25 Nov 2005, Harald Welte wrote:
>>
>>> yes.  old libnetfilter_conntrack is broken, because it makes wrong size
>>> assumptions.  But if we'd start introdcucing the "new scheme" I
>>> proposed, we can guarantee not to run into any of these.
>>
>>
>> Only if new libnetfilter_conntrack will send different messages to
>> differnet kernels (u_int16_t for 2.6.14 and u_int8_t for 2.6.15+).
> 
> I also thinks its a large overkill to introduce this scheme just to
> handle brokeness, lets just try not to make this kind of mistake again.
> Also it doesn't handle the byteorder-problem of this particular case,
> so I don't think we should go this way.

I agree. Sorry, I'm not willing to be repetitive but I still see a
possible workaround as something ugly that we'll have to live with
forever because of an early mistake in the development. If there will be
more 2.6.14.x release, fixing it there can be a choice. In spite of
everything, I understand that breaking backward compatibility isn't nice
but in this case ctnetlink just got pushed forward and it's barely one
month old.

-- 
Pablo