From owner-freebsd-net Fri Aug 3 13:39:15 2001 Delivered-To: freebsd-net@freebsd.org Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by hub.freebsd.org (Postfix) with ESMTP id 532C537B407 for ; Fri, 3 Aug 2001 13:39:11 -0700 (PDT) (envelope-from itojun@itojun.org) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5F9EC4B23; Sat, 4 Aug 2001 05:38:50 +0900 (JST) To: Bill Fenner Cc: mlnn4@oaks.com.au, freebsd-net@freebsd.org In-reply-to: fenner's message of Fri, 03 Aug 2001 10:53:13 MST. <200108031753.KAA19454@windsor.research.att.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: kernel upgrade causes truncated IPSEC packets From: itojun@iijlab.net Date: Sat, 04 Aug 2001 05:38:50 +0900 Message-ID: <4738.996871130@itojun.org> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >> was the fix committed to sys/net/if_tun.c? i guess other *BSDs have >> the same issue. >I just committed it. >If anyone is interested in tracking down the problem in the IPSEC stack, >the problem only seems to occur when the data is in a cluster mbuf >(thus Chris's observation that small packets get through). My observation >was: >mbuf 1: IP header >mbuf 2: AH header >mbuf 3: ESP header >mbuf 4: 0 length >mbuf 5: cluster mbuf containing data this is perfectly legal, and can happen by result of m_cat()/m_split() calls from ipsec code. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message