From owner-freebsd-net@FreeBSD.ORG Fri Sep 14 19:57:05 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A5A216A41A for ; Fri, 14 Sep 2007 19:57:05 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outK.internet-mail-service.net (outK.internet-mail-service.net [216.240.47.234]) by mx1.freebsd.org (Postfix) with ESMTP id 06E4B13C45D for ; Fri, 14 Sep 2007 19:57:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Fri, 14 Sep 2007 12:57:03 -0700 Received: from julian-mac.elischer.org (nat.ironport.com [63.251.108.100]) by idiom.com (Postfix) with ESMTP id 5C1191263AD; Fri, 14 Sep 2007 12:57:03 -0700 (PDT) Message-ID: <46EAE78D.8060108@elischer.org> Date: Fri, 14 Sep 2007 12:57:01 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Christensen , FreeBSD Net , Jack Vogel Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: BCE on FreeBSD and oversized packet acceptance. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 19:57:05 -0000 more on this issue: 802.3-2000 expanded the maximum frame size for standard ethernet to 1522 bytes (including vlan header, ethernet header and CRC). however this has produced quite a bit of confusion with HP telling their custommers to set their MTUs on equipment to 1522, which in turn has packets of 1522+vlan_header+CRC+etherhedr (i.e. too big) floating around some networks. When we try to connect our FreeBSD based products on these networks thigns go badly. Sure they've misconfigured their networks but telling a bank to reconfigure their network with all the change-control they have, is a sure fire way to lose a $100,000 deal. Our action has been to relax the discard limit on various drivers, but it'd be nice if we didn't have to keep separate diffs for this. I discussed it a while back on net but the discussion was mostly about the code in if_ethersubr.c (since deleted) that did the same. I'd like to just ask around as to whether relaxing the limit on drivers makes sense, and if so, how much to relax it. While we're about it, what size is the actual maximal sized jumbo packet we will ever see? (including likely misconfigurations). It is possible we should just allow any packet that fits into the allocated memory, though one might suggest we just allow say 32 bytes of leeway or something. Julian