From owner-freebsd-hackers Sun Jul 6 16:57:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12341 for hackers-outgoing; Sun, 6 Jul 1997 16:57:46 -0700 (PDT) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA12336 for ; Sun, 6 Jul 1997 16:57:43 -0700 (PDT) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id QAA18592 for ; Sun, 6 Jul 1997 16:57:13 -0700 (PDT) Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3) id sma018590; Sun Jul 6 16:56:47 1997 Received: (from archie@localhost) by bubba.whistle.com (8.8.5/8.6.12) id QAA13745 for freebsd-hackers@FreeBSD.ORG; Sun, 6 Jul 1997 16:56:47 -0700 (PDT) From: Archie Cobbs Message-Id: <199707062356.QAA13745@bubba.whistle.com> Subject: Re: VJ compression and MAX_HDR In-Reply-To: <199707062332.QAA13618@bubba.whistle.com> from Archie Cobbs at "Jul 6, 97 04:32:28 pm" To: freebsd-hackers@FreeBSD.ORG Date: Sun, 6 Jul 1997 16:56:47 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In slcompress.h, MAX_HDR is defined so: > > #define MAX_HDR MLEN /* XXX 4bsd-ism: should really be 128 */ > > MLEN is like 108 or something. > > This means that when Van Jacobson compression is active, any packets > sent to us with combined IP and TCP header length greater than MLEN > will be dropped, always. > > This is an admittedly rare case, but my question is, why was this > done? What code would break if MAX_HDR is changed back to 128? > > Searching for "MAX_HDR" in every source file in /usr/src/sys shows > that it only appears in slcompress.c and slcompress.h; moreover, > the code in if_ppp.c and if_sl.c seems to properly handle uncompressed > headers having length greater than MLEN (from a cursory glance). > > Therefore, may I propose the following patch? Or else someone please > elighten me. After further review, it looks like the genesis of this change is the fact that sl_compress_tcp() requires the full TCP/IP headers to lie within the first mbuf, and sl_uncompress_tcp() requires the TCP/IP header (in the TYPE_UNCOMPRESSED_TCP case) to also be in a contiguous buffer... Plus the fact that m_pullup() won't work for values greater than MHLEN doesn't help. Hmm.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com