From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FaWGm-0001kS-4a
	for qemu-devel@nongnu.org; Mon, 01 May 2006 07:08:48 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FaWGl-0001kD-KH
	for qemu-devel@nongnu.org; Mon, 01 May 2006 07:08:47 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FaWGl-0001k3-Eh
	for qemu-devel@nongnu.org; Mon, 01 May 2006 07:08:47 -0400
Received: from [84.96.92.60] (helo=Smtp.neuf.fr)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1FaWKY-0008K9-Ma
	for qemu-devel@nongnu.org; Mon, 01 May 2006 07:12:42 -0400
Received: from [84.102.211.147] by sp604001mt.gpm.neuf.ld
	(Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006))
	with ESMTP id <0IYL007Q32YMQSG0@sp604001mt.gpm.neuf.ld> for
	qemu-devel@nongnu.org; Mon, 01 May 2006 13:08:46 +0200 (CEST)
Date: Mon, 01 May 2006 13:08:03 +0200
From: Fabrice Bellard <fabrice@bellard.org>
Subject: Re: [Qemu-devel] [PATCH] Fix scrambling of >32KB packets in slirp
In-reply-to: <c1bf1cf0604301955tc9f402r763c3d125479f1b9@mail.gmail.com>
Message-id: <4455EC13.9040000@bellard.org>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
References: <c1bf1cf0604301955tc9f402r763c3d125479f1b9@mail.gmail.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Ed Swierk wrote:
> In several places in qemu's slirp code, signed and unsigned ints are
> used interchangeably when dealing with IP packet lengths and offsets.
> This causes IP packets greater than 32K in length to be scrambled in
> various interesting ways that are extremely difficult to troubleshoot.
> 
> Although large IP packets are fairly rare in practice, certain
> UDP-based protocols like NFS use them extensively.
> 
> The attached patch wraps IP packet lengths and offsets in macros that
> ensure they are always properly treated as unsigned values.

Why not changing the definition itself to uint16_t and verifying each 
occurence of ip_off and ip_len ?

Fabrice.