From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Subject: 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) Date: Fri, 25 Nov 2005 01:22:03 +0100 Message-ID: <4386592B.1000905@eurodev.net> References: <4381FDF8.6030508@trash.net> <43820874.2050708@eurodev.net> <4382A19D.9090201@trash.net> <43836BAF.2050501@eurodev.net> <20051122220606.GC31478@sunbeam.de.gnumonks.org> <4383C2C9.8050109@eurodev.net> <43843ACE.4050808@trash.net> <20051124200736.GW31478@sunbeam.de.gnumonks.org> <20051124202125.GX31478@sunbeam.de.gnumonks.org> <43864DC7.6060109@trash.net> <438656AE.9020307@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Harald Welte , Netfilter Development Mailinglist Return-path: To: Patrick McHardy In-Reply-To: <438656AE.9020307@trash.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Patrick McHardy wrote: > Krzysztof Oledzki wrote: > >> Old binaries are not able to deal with CTA_PROTO and will not be able >> to parse this attribute received from kernel. We should keep >> CTA_PROTO_NUM here, but this leads to u_int8_t/u_int16_t mismatch in >> the code. > > I didn't notice that, we of course need to dump both attributes. But I > still think Pablo's suggestion is fine too and avoids all these hacks. > The only people affected will be the ones not using the stable series. Same feeling. I don't like the idea of breaking backward compatibility, but in this case the hacks don't look really nice either :(. Since this stuff was just pushed forward to 2.6.14, I still think that we should send a patch to fix it in -stable. -- Pablo