From owner-freebsd-arch Mon Sep 2 12:47:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEF8637B409 for ; Mon, 2 Sep 2002 12:47:19 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2ED343E81 for ; Mon, 2 Sep 2002 12:47:13 -0700 (PDT) (envelope-from justin@mac.com) Received: from smtp-relay01.mac.com (smtp-relay01-en1 [10.13.10.224]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id g82JikKw029121 for ; Mon, 2 Sep 2002 12:44:46 -0700 (PDT) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtp-relay01.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g82JijVw022705 for ; Mon, 2 Sep 2002 12:44:46 -0700 (PDT) Received: from lightnin ([12.234.224.67]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H1TTIL00.P5R for ; Mon, 2 Sep 2002 12:44:45 -0700 Date: Mon, 2 Sep 2002 14:44:52 -0500 Subject: Re: Ethernet packet padding: How much is legal? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: "Justin C. Walker" To: arch@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: <20020902140522.W281-100000@patrocles.silby.com> Message-Id: <732CD7A3-BEAC-11D6-92CC-000393575CAC@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday, September 2, 2002, at 02:19 , Mike Silbersack wrote: > This may be offtopic for the list, but I know that some of you guys will > know the answer to this question. :) > > Despite the overall success of the recent patches to the if_vr > driver, Thomas Nystrom and Jean Delvare have continued to search for the > root of the problems in the if_vr hardware. > > In short, they've found that if a 1500 byte packet + a small fragment > adding up to approximately 2K are sent in quick succession, the small > fragment will be dropped. This appears to be a bug in the Via Rhine > hardware, so we're brainstorming on ways to work around this problem. > > One option we're seriously looking at is padding all ethernet packets > within a certain size (400 - 600 bytes in size) up to 600 bytes. This > would be done in vr_encap just as padding to minimum packet size is done > currently: > > > if (m_head->m_len < VR_MIN_FRAMELEN) { > m_new->m_pkthdr.len += VR_MIN_FRAMELEN - > m_new->m_len; > m_new->m_len = m_new->m_pkthdr.len; > } > + if ((m_head->m_len > 400) && (m_head->m_len < 800)) { > + m_new->m_pkthdr.len = 800; > + m_new->m_len = m_new->m_pkthdr.len; > + } > > Thomas says that the above preliminary patch seems to solve the problem, > so it looks like a workable solution if we can more exactly determine > the > range in which we need to pad. (And perhaps only pad if the preceeding > packet is a full size frame, etc - this is still being researched.) > > Anyway, now to the real question: Is adding arbitrary padding like this > going to break anything? IP seems content, but will other protocols be > broken by extra ethernet padding? Although we don't support too many > protocols, the card could be passing all sorts of packets if it is used > for bridging. I'll hazard a guess that it's OK, unless there are protocols that live or die by the inferred length of a packet, rather than information in the packet itself. I don't know of any off-hand. I'm assuming that your code (above) doesn't actually affect internal length indicators, and just transmits extra bytes. For ethernet-2 (like IP/ARP), I can't say for sure that encapsulated protocols all carry their own lengths. IP does (AFAIK; most transport protocols seem to include their own length), and ARP is fixed-size. For 802.x, I believe that the length of the media frame is always present (as opposed to the network packet, as in IP). One thing to be wary of is IPX - it's got a zillion frame formats (OK, four) and at least one doesn't include a media frame length. Of course, there's always the question of whether a receiving driver will get bent out of shape if the stated (in the frame) length is smaller than the received length. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message