From owner-freebsd-net Thu Aug 2 5:37:26 2001 Delivered-To: freebsd-net@freebsd.org Received: from aussie.org (hallam.lnk.telstra.net [139.130.54.166]) by hub.freebsd.org (Postfix) with ESMTP id 9775837B403 for ; Thu, 2 Aug 2001 05:37:22 -0700 (PDT) (envelope-from mlnn4@oaks.com.au) Received: from dualp2 (dualp2 [203.29.75.73]) by aussie.org (8.11.3/8.11.4) with SMTP id f72CbKQ00596 for ; Thu, 2 Aug 2001 22:37:20 +1000 (EST) (envelope-from mlnn4@oaks.com.au) Message-Id: <200108021237.f72CbKQ00596@aussie.org> From: "Chris" To: "freebsd-net@freebsd.org" Date: Thu, 02 Aug 2001 22:36:06 +1000 Reply-To: "Chris" X-Mailer: PMMail 98 Standard (2.01.1600) For Windows NT (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: re: kernel upgrade causes truncated IPSEC packets 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 >packet. But the PPP process only sees the first 36 bytes or so of it (for >example, a packet which arrives as 263 bytes becomes 320 bytes after >encapsulation. This is what is shown by both tcpdump and the packet header, >as read from the ppp async stream), but only 36 bytes of it make it through >to the modem (plus the PPP overhead of about 5 bytes). I re-posted this to -stable, and thanks to Bill Fenner it is now fixed. It seems that the IPSEC code for some reason will sometimes insert a zero- length mbuf into the mbuf chain. if_tun.c will cease following the linked list of mbufs if it sees a zero-length one, thus causing the truncated output packets. Dunno how long it's been like that (probably 7 weeks) but it would have affected anyone who used IPSEC over a /dev/tunN device. -- Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message