CTA_PROTO_NUM u_int8_t or u_int16_t

Krzysztof Oledzki olenf at ans.pl
Mon Nov 21 22:26:43 CET 2005



On Mon, 21 Nov 2005, Pablo Neira wrote:

> Patrick McHardy wrote:
>> Pablo Neira wrote:
>>
>>> Krzysztof Oledzki wrote:
>>>
>>>> AFAIK ip proto is u8 but I found that it is represented as u16 and used
>>>> both as u_int16_t and u_int8_t:
>>>>
>>>> include/linux/netfilter_ipv4/ipt_conntrack.h:           u16 protonum;
>>>>
>>>> net/ipv4/netfilter/ip_conntrack_netlink.c:      NFA_PUT(skb,
>>>> CTA_PROTO_NUM, sizeof(u_int8_t), &tuple->dst.protonum);
>>>> net/ipv4/netfilter/ip_conntrack_netlink.c:
>>>> [CTA_PROTO_NUM-1]      = sizeof(u_int16_t),
>>>> net/ipv4/netfilter/ip_conntrack_netlink.c:      tuple->dst.protonum =
>>>> *(u_int16_t *)NFA_DATA(tb[CTA_PROTO_NUM-1]);
>>>>
>>>> Was this intentionally?
>>>
>>>
>>> No :(, it has slipped through at some stage. I was aware of that, I
>>> found it some days ago. The problem is that if we fix that we could
>>> break backward compatibility for 2.6.14, so I'm still thinking about how
>>> to fix it.
>>
>> If you have to break compatibility, please do it before 2.6.15 is
>> released. But the easiest solution looks like keeping it a u_int16_t
>> and adjusting the NFA_PUT.
>
> I think that I can fix it in nf_conntrack_netlink. ip_conntrack_netlink
> will go sooner or later.

Fair enough. But what if we find similar problem later, this time in 
nf_conntrack_netlink? ;)

Best regards,

 				Krzysztof Olędzki


More information about the netfilter-devel mailing list