From owner-freebsd-net@FreeBSD.ORG Thu Sep 6 22:26:08 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 67E6416A417 for ; Thu, 6 Sep 2007 22:26:08 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outL.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id 4B25113C45A for ; Thu, 6 Sep 2007 22:26:08 +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; Thu, 06 Sep 2007 15:25:57 -0700 Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 126EA1262DE for ; Thu, 6 Sep 2007 15:25:57 -0700 (PDT) Message-ID: <46E07E74.5020204@elischer.org> Date: Thu, 06 Sep 2007 15:25:56 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: FreeBSD Net References: <46E0632D.8070200@elischer.org> In-Reply-To: <46E0632D.8070200@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD discarding received packets > MTU 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: Thu, 06 Sep 2007 22:26:08 -0000 Julian Elischer wrote: > Ok which clever person did this again? > > It just broke our product. > If it hasn't been removed from 7.0 and 6.x yet it's just about to be... > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" on the topic above, I've found that the bce driver seems to be throwingaway packets larger than the mtu regardless of the rest of the system.. the following code seems to be responsible.. in the spirit of "be generous on receive" as mentionned before, should it be relaxed? /* Calculate and program the Ethernet MTU size. */ ether_mtu = ETHER_HDR_LEN + ETHER_VLAN_ENCAP_LEN + ifp->if_mtu + ETHER_CRC_LEN; DBPRINT(sc, BCE_INFO, "%s(): setting mtu = %d\n",__FUNCTION__, ether_mtu); /* * Program the mtu, enabling jumbo frame * support if necessary. Also set the mbuf * allocation count for RX frames. */ if (ether_mtu > ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN) { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu | BCE_EMAC_RX_MTU_SIZE_JUMBO_ENA); sc->mbuf_alloc_size = MJUM9BYTES; } else { REG_WR(sc, BCE_EMAC_RX_MTU_SIZE, ether_mtu); sc->mbuf_alloc_size = MCLBYTES; } could probably be relaxed in the non jumbo case to accept packets up to MCLBYTES in size instead of ether_mtu. manually I have set the mtu to larger values which increases ether_mtu and that seems to work.. now, Why do we need this? WCCP is a protocol from Cisco. it encapsulates packets in GRE, including an extra intermediate header. when packets are encapsulated in GRE by cisco 6k switches (quite a few around) they do NOT frag the result, but instead, send an oversized packet. if you have a bce interface, it discards these packets which is a drag.