From rea@rea.mbslab.kiae.ru  Tue Mar 14 15:42:53 2006
Return-Path: <rea@rea.mbslab.kiae.ru>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8D6F616A401
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Mar 2006 15:42:53 +0000 (UTC)
	(envelope-from rea@rea.mbslab.kiae.ru)
Received: from rea.mbslab.kiae.ru (rea.mbslab.kiae.ru [144.206.177.25])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 22C9843D46
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Mar 2006 15:42:53 +0000 (GMT)
	(envelope-from rea@rea.mbslab.kiae.ru)
Received: from rea.mbslab.kiae.ru (localhost [127.0.0.1])
	by rea.mbslab.kiae.ru (Postfix) with ESMTP id 3FA4BBAA1;
	Tue, 14 Mar 2006 18:42:51 +0300 (MSK)
Received: by rea.mbslab.kiae.ru (Postfix, from userid 1000)
	id 18472BA9F; Tue, 14 Mar 2006 18:42:51 +0300 (MSK)
Message-Id: <20060314154251.18472BA9F@rea.mbslab.kiae.ru>
Date: Tue, 14 Mar 2006 18:42:51 +0300 (MSK)
From: Eygene A.Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
Reply-To: Eygene A.Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: FreeBSD-gnats-submit@freebsd.org
Cc: rea-fbsd@rea.mbslab.kiae.ru
Subject: if_bridge modifies IP length and offset fields for broadcast packets
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         94448
>Category:       kern
>Synopsis:       [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    rik
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 14 15:50:07 GMT 2006
>Closed-Date:    Mon Apr 03 07:53:49 GMT 2006
>Last-Modified:  Mon Apr 03 07:53:49 GMT 2006
>Originator:     Eygene A. Ryabinkin
>Release:        FreeBSD 6.1-PRERELEASE i386
>Organization:
Code Labs
>Environment:
System: FreeBSD XXXX 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #35: Tue Mar 7 20:15:22 MSK 2006 root@XXXX:/usr/obj/usr/src/sys/XXXX i386


	
>Description:
 if_bridge swaps IP length and header fields in the broadcast packets flowing
through the bridge. This affects only architectures where native byte order
is not the networking one (bid endian). Not all packets are touched: only
packets that are rejected by the firewall (any that installs pfil hooks)
can be modified this way. The bridges with only two interfaces are not
affected: the bug exists, but it will not lead to swapping. Bridges that
do not use firewalling are also unaffected.

 The reason lies in the /sys/net/if_bridge.c, line 2095:
     mc = m_copypacket(m, M_DONTWAIT);
and then the mbuf 'mc' will be passed to the bridge_pfil(), where IP
header fields 'length' and 'offset' will be transformed to the native
host byte order before applying pfil hooks. If any pfil hook will reject
the packet it will free mbuf and NULL'ify the mbuf pointer, but since
this mbuf is just the result of m_copypacket(), the packet's IP
header will be screwed a bit. And the next interface will get the
bad IP header.

 As far as I understand, this error lives in FreeBSD 5.x as well. Though
I do not have any 5.x at hand to test it, judging only by the code.
>How-To-Repeat:
 Set up if_bridge with three or more interfaces and try to send broadcast
packets from one bridge branch. Set up the firewall to reject broadcasts
on some interface. Watch for broadcasts with tcpdump on all bridge
interfaces and you will see that some interfaces will get the bad
packet.
>Fix:
 Replace m_copypacket() with m_dup():
-----
--- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
+++ if_bridge.c	Tue Mar 14 18:05:50 2006
@@ -2092,7 +2092,11 @@
 			mc = m;
 			used = 1;
 		} else {
-			mc = m_copypacket(m, M_DONTWAIT);
+			/*
+			 * Doing the m_dup here, because this mbuf can be
+			 * passed to pfil_hook and modified.
+			 */
+			mc = m_dup(m, M_DONTWAIT);
 			if (mc == NULL) {
 				sc->sc_ifp->if_oerrors++;
 				continue;
-----
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->	 rik  
Responsible-Changed-By: rik 
Responsible-Changed-When: Tue Mar 14 16:22:02 UTC 2006 
Responsible-Changed-Why:  
I'll take care of it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94448 

From: Andrew Thompson <thompsa@freebsd.org>
To: bug-followup@freebsd.org, rea-fbsd@rea.mbslab.kiae.ru, rik@freebsd.org
Cc:  
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Wed, 15 Mar 2006 09:28:00 +1300

 The alignment of the copied mbuf needs to be kept. Changing it stright
 to m_dup() will give a 'memory address not aligned' panic on sparc64 (when
 using with a packet filter). This was changed in r1.15.
 
 cheers,
 Andrew

From: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Wed, 15 Mar 2006 13:49:21 +0300

 > The alignment of the copied mbuf needs to be kept. Changing it stright
 > to m_dup() will give a 'memory address not aligned' panic on sparc64 (when
 > using with a packet filter). This was changed in r1.15.
  Yes, I see it now and I agree that alignment is good. But as far as I see
 from the if_bridge.c, it does m_dup() on the incoming multicast packets
 and passes the copy of mbuf to the bridge_forward(). No alignment is present
 or I am missing something? Or this has to be changed as well?
 
  I'm new to mbuf internals, so may be I'm asking stupid questions. Forgive
 me then.
 -- 
 Eygene

From: Andrew Thompson <thompsa@freebsd.org>
To: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
Cc: bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Wed, 15 Mar 2006 23:56:07 +1300

 On Wed, Mar 15, 2006 at 01:49:21PM +0300, Eygene Ryabinkin wrote:
 > > The alignment of the copied mbuf needs to be kept. Changing it stright
 > > to m_dup() will give a 'memory address not aligned' panic on sparc64 (when
 > > using with a packet filter). This was changed in r1.15.
 >  Yes, I see it now and I agree that alignment is good. But as far as I see
 > from the if_bridge.c, it does m_dup() on the incoming multicast packets
 > and passes the copy of mbuf to the bridge_forward(). No alignment is present
 > or I am missing something? Or this has to be changed as well?
 > 
 >  I'm new to mbuf internals, so may be I'm asking stupid questions. Forgive
 > me then.
 
 The alignment is only needed for passing off to pfil(9). In
 bridge_ip*_checkbasic() the alignment is adjusted for incoming packets
 (not on outgoing), so only copied mbufs in the broadcast code which are
 outgoing have this problem.
 
 I guess the solution may be to align all pfil'd packets, in and out?
 
 
 Andrew

From: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Wed, 15 Mar 2006 14:28:50 +0300

 > The alignment is only needed for passing off to pfil(9). In
 > bridge_ip*_checkbasic() the alignment is adjusted for incoming packets
 > (not on outgoing), so only copied mbufs in the broadcast code which are
 > outgoing have this problem.
  Exactly, thanks for the explanation!
 > 
 > I guess the solution may be to align all pfil'd packets, in and out?
  It is the one way, I guess it can be done via m_align(). But I'm a bit
 worried by the paragraph in the pfil(9):
 -----
      When a filter is invoked, the packet appears just as if it ``came off the
      wire''.  That is, all protocol fields are in network byte order.
 -----
 So, we could leave the m_copypacket() in place, if the pfil can be told
 that this packet is in the network byte order. Judging by the code in
 /sys/net/ip_fw_pfil.c and /sys/contrib/ipfilter/netinet/fil.c it is not
 the case. So either
  a) I am wrong in my understanding of the manual page,
  b) the manual page is wrong.
 
  I'm buzzing about keeping m_copypacket, because it seems to be faster and
 less memory-consuming. But may be it is not worth the things and we should
 just add m_align() to the m_dup(). I can not judge here, maybe you can
 say something?
 
  And the third way is to check the reference count of mbuf in the bridge_pfil
 and restore normal byte order if filter consumed a copy of the packet, but
 there are another copies. Looks like a dirty hack and I am not sure if it
 can be done properly in the multithreaded kernel.
 -- 
 Eygene

From: Andrew Thompson <thompsa@freebsd.org>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Thu, 16 Mar 2006 10:51:40 +1300

 Lets see if the new m_unshare() routine will help in this situation.

From: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Thu, 16 Mar 2006 17:13:08 +0300

 > I guess the solution may be to align all pfil'd packets, in and out?
  Tried to align just the packets copied by the m_dup() in the bridge_broadcast.
 The patch was changed:
 -----
 --- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
 +++ if_bridge.c	Thu Mar 16 16:58:39 2006
 @@ -2047,7 +2047,7 @@
  	struct bridge_iflist *bif;
  	struct mbuf *mc;
  	struct ifnet *dst_if;
 -	int error = 0, used = 0;
 +	int error = 0, used = 0, len;
  
  	BRIDGE_LOCK_ASSERT(sc);
  	BRIDGE_LOCK2REF(sc, error);
 @@ -2092,7 +2092,17 @@
  			mc = m;
  			used = 1;
  		} else {
 -			mc = m_copypacket(m, M_DONTWAIT);
 +			/*
 +			 * Doing the m_dup here, because this mbuf can be
 +			 * passed to pfil_hook and modified.
 +			 */
 +			mc = m_dup(m, M_DONTWAIT);
 +			if (mc == NULL) {
 +				sc->sc_ifp->if_oerrors++;
 +				continue;
 +			}
 +			len = min(mc->m_pkthdr.len, max_protohdr);
 +			mc = m_copyup(mc, len, ETHER_ALIGN);
  			if (mc == NULL) {
  				sc->sc_ifp->if_oerrors++;
  				continue;
 -----
 Please, try it on the sparc64, if you have one at hand. It works fine on
 the i386, and I do not have another architectures to test on.
 -- 
 Eygene

From: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Thu, 16 Mar 2006 17:13:08 +0300

 > I guess the solution may be to align all pfil'd packets, in and out?
  Tried to align just the packets copied by the m_dup() in the bridge_broadcast.
 The patch was changed:
 -----
 --- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
 +++ if_bridge.c	Thu Mar 16 16:58:39 2006
 @@ -2047,7 +2047,7 @@
  	struct bridge_iflist *bif;
  	struct mbuf *mc;
  	struct ifnet *dst_if;
 -	int error = 0, used = 0;
 +	int error = 0, used = 0, len;
  
  	BRIDGE_LOCK_ASSERT(sc);
  	BRIDGE_LOCK2REF(sc, error);
 @@ -2092,7 +2092,17 @@
  			mc = m;
  			used = 1;
  		} else {
 -			mc = m_copypacket(m, M_DONTWAIT);
 +			/*
 +			 * Doing the m_dup here, because this mbuf can be
 +			 * passed to pfil_hook and modified.
 +			 */
 +			mc = m_dup(m, M_DONTWAIT);
 +			if (mc == NULL) {
 +				sc->sc_ifp->if_oerrors++;
 +				continue;
 +			}
 +			len = min(mc->m_pkthdr.len, max_protohdr);
 +			mc = m_copyup(mc, len, ETHER_ALIGN);
  			if (mc == NULL) {
  				sc->sc_ifp->if_oerrors++;
  				continue;
 -----
 Please, try it on the sparc64, if you have one at hand. It works fine on
 the i386, and I do not have another architectures to test on.
 -- 
 Eygene

From: Roman Kurakin <rik@inse.ru>
To: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
Cc: Andrew Thompson <thompsa@freebsd.org>,  bug-followup@freebsd.org, 
 rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length
 and offset fields for broadcast packets
Date: Mon, 20 Mar 2006 10:40:36 +0300

 Eygene Ryabinkin:
 
 >>I guess the solution may be to align all pfil'd packets, in and out?
 >>    
 >>
 > Tried to align just the packets copied by the m_dup() in the bridge_broadcast.
 >The patch was changed:
 >  
 >
 What about this one:
 
  --- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
  +++ if_bridge.c	Thu Mar 16 16:58:39 2006
  @@ -2047,7 +2047,7 @@
   	struct bridge_iflist *bif;
   	struct mbuf *mc;
   	struct ifnet *dst_if;
  -	int error = 0, used = 0;
  +	int error = 0, used = 0, len;
   
   	BRIDGE_LOCK_ASSERT(sc);
   	BRIDGE_LOCK2REF(sc, error);
  @@ -2092,7 +2092,26 @@
   			mc = m;
   			used = 1;
   		} else {
  -			mc = m_copypacket(m, M_DONTWAIT);
  +			/*
  +			 * Doing the m_dup here, because this mbuf can be
  +			 * passed to pfil_hook and modified.
  +			 */
  +			mc = m_dup(m, M_DONTWAIT);
  +			if (mc == NULL) {
  +				sc->sc_ifp->if_oerrors++;
  +				continue;
  +			}
  +        		if (IP_HDR_ALIGNED_P(mtod(mc, caddr_t)) == 0) {
  +                		if ((mc = m_copyup(mc, sizeof(struct ip),
  +                        		(max_linkhdr + 3) & ~3)) == NULL) {
  +					sc->sc_ifp->if_oerrors++;
  +					continue;
  +                		}
  +			} else if (__predict_false(mc->m_len < sizeof (struct ip))) {
  +               		if ((mc = m_pullup(mc, sizeof (struct ip))) == NULL) {
  +					sc->sc_ifp->if_oerrors++;
  +					continue;
  +                	}
 
   			if (mc == NULL) {
   				sc->sc_ifp->if_oerrors++;
   				continue;
 
 I guess we were talking about IP not ETHER alignment. Andrew what do you 
 think about this
 patch and if it is Ok, could you test it on Sparc (I do not have access 
 to any)?
 
 (PS. Patch is handmade and wasn't even tested for compilation)
 
 rik
 
 >-----
 >--- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
 >+++ if_bridge.c	Thu Mar 16 16:58:39 2006
 >@@ -2047,7 +2047,7 @@
 > 	struct bridge_iflist *bif;
 > 	struct mbuf *mc;
 > 	struct ifnet *dst_if;
 >-	int error = 0, used = 0;
 >+	int error = 0, used = 0, len;
 > 
 > 	BRIDGE_LOCK_ASSERT(sc);
 > 	BRIDGE_LOCK2REF(sc, error);
 >@@ -2092,7 +2092,17 @@
 > 			mc = m;
 > 			used = 1;
 > 		} else {
 >-			mc = m_copypacket(m, M_DONTWAIT);
 >+			/*
 >+			 * Doing the m_dup here, because this mbuf can be
 >+			 * passed to pfil_hook and modified.
 >+			 */
 >+			mc = m_dup(m, M_DONTWAIT);
 >+			if (mc == NULL) {
 >+				sc->sc_ifp->if_oerrors++;
 >+				continue;
 >+			}
 >+			len = min(mc->m_pkthdr.len, max_protohdr);
 >+			mc = m_copyup(mc, len, ETHER_ALIGN);
 > 			if (mc == NULL) {
 > 				sc->sc_ifp->if_oerrors++;
 > 				continue;
 >-----
 >Please, try it on the sparc64, if you have one at hand. It works fine on
 >the i386, and I do not have another architectures to test on.
 >  
 >
 

From: Andrew Thompson <thompsa@freebsd.org>
To: Roman Kurakin <rik@inse.ru>
Cc: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>, bug-followup@freebsd.org,
        rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Mon, 20 Mar 2006 22:23:19 +1200

 On Mon, Mar 20, 2006 at 10:40:36AM +0300, Roman Kurakin wrote:
 > >
 > What about this one:
 > 
 > --- if_bridge.c.orig	Tue Mar 14 17:32:02 2006
 > +++ if_bridge.c	Thu Mar 16 16:58:39 2006
 > @@ -2047,7 +2047,7 @@
 >
 > +        		if (IP_HDR_ALIGNED_P(mtod(mc, caddr_t)) == 0) {
 > +                		if ((mc = m_copyup(mc, sizeof(struct ip),
 > +                        		(max_linkhdr + 3) & ~3)) == NULL) {
 > +					sc->sc_ifp->if_oerrors++;
 > +					continue;
 > +                		}
 > +			} else if (__predict_false(mc->m_len < sizeof 
 > (struct ip))) {
 > +               		if ((mc = m_pullup(mc, sizeof (struct ip))) 
 > == NULL) {
 > +					sc->sc_ifp->if_oerrors++;
 > +					continue;
 > +                	}
 
 Thats ipv4 specific, I am happy with this patch and it passes the test
 on sparc64. Its similar to Eygene's patch but has the benifit of only
 aligning if we are doing a bridge_pfil() and it only aligns the duped
 packet so there is no performance hit on a 2 interface bridge.
 
 Can you test this Eygene?
 
 
 
 Index: if_bridge.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/net/if_bridge.c,v
 retrieving revision 1.56
 diff -u -p -r1.56 if_bridge.c
 --- if_bridge.c	3 Mar 2006 09:12:21 -0000	1.56
 +++ if_bridge.c	20 Mar 2006 10:09:35 -0000
 @@ -2076,7 +2076,7 @@ bridge_broadcast(struct bridge_softc *sc
  	struct bridge_iflist *bif;
  	struct mbuf *mc;
  	struct ifnet *dst_if;
 -	int error = 0, used = 0;
 +	int error = 0, used = 0, i;
  
  	BRIDGE_LOCK_ASSERT(sc);
  	BRIDGE_LOCK2REF(sc, error);
 @@ -2121,7 +2121,7 @@ bridge_broadcast(struct bridge_softc *sc
  			mc = m;
  			used = 1;
  		} else {
 -			mc = m_copypacket(m, M_DONTWAIT);
 +			mc = m_dup(m, M_DONTWAIT);
  			if (mc == NULL) {
  				sc->sc_ifp->if_oerrors++;
  				continue;
 @@ -2138,6 +2138,15 @@ bridge_broadcast(struct bridge_softc *sc
  		    || PFIL_HOOKED(&inet6_pfil_hook)
  #endif
  		    )) {
 +			if (used == 0) {
 +				/* Keep the layer3 header aligned */
 +				i = min(mc->m_pkthdr.len, max_protohdr);
 +				mc = m_copyup(mc, i, ETHER_ALIGN);
 +				if (mc == NULL) {
 +					sc->sc_ifp->if_oerrors++;
 +					continue;
 +				}
 +			}
  			if (bridge_pfil(&mc, NULL, dst_if, PFIL_OUT) != 0)
  				continue;
  			if (mc == NULL)

From: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
To: Andrew Thompson <thompsa@freebsd.org>
Cc: Roman Kurakin <rik@inse.ru>, bug-followup@freebsd.org, rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Tue, 21 Mar 2006 11:39:14 +0300

 > Thats ipv4 specific, I am happy with this patch and it passes the test
 > on sparc64. Its similar to Eygene's patch but has the benifit of only
 > aligning if we are doing a bridge_pfil() and it only aligns the duped
 > packet so there is no performance hit on a 2 interface bridge.
 > 
 > Can you test this Eygene?
  Your patch is also fine: I see no corrupted packets. Looks like it is
 the final one. I will watch my bridge closely and will tell you if
 something will go wrong with this patch.
 
  Andrew, one stupid question: am I right that new mbuf is created at the
 double word boundary (or some arch-specific boundary), so to align the
 Ethernet packet load we should move it ETHER_ALIGN (2 on i386) bytes up?

From: Roman Kurakin <rik@inse.ru>
To: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>
Cc: Andrew Thompson <thompsa@freebsd.org>,  bug-followup@freebsd.org, 
 rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length
 and offset fields for broadcast packets
Date: Tue, 21 Mar 2006 12:08:47 +0300

 Eygene Ryabinkin:
 
 >>Thats ipv4 specific, I am happy with this patch and it passes the test
 >>on sparc64. Its similar to Eygene's patch but has the benifit of only
 >>aligning if we are doing a bridge_pfil() and it only aligns the duped
 >>packet so there is no performance hit on a 2 interface bridge.
 >>
 >>Can you test this Eygene?
 >>    
 >>
 > Your patch is also fine: I see no corrupted packets. Looks like it is
 >the final one. I will watch my bridge closely and will tell you if
 >something will go wrong with this patch.
 >  
 >
 Ok, I'll commit this patch to the current and lets it sit there a week 
 before MFC-ing.
 
 rik
 
 > Andrew, one stupid question: am I right that new mbuf is created at the
 >double word boundary (or some arch-specific boundary), so to align the
 >Ethernet packet load we should move it ETHER_ALIGN (2 on i386) bytes up?
 >  
 >
 

From: Andrew Thompson <thompsa@freebsd.org>
To: Roman Kurakin <rik@inse.ru>
Cc: Eygene Ryabinkin <rea-fbsd@rea.mbslab.kiae.ru>, bug-followup@freebsd.org,
        rik@freebsd.org
Subject: Re: kern/94448: [if_bridge] [patch] if_bridge modifies IP length and offset fields for broadcast packets
Date: Fri, 24 Mar 2006 10:40:48 +1200

 On Tue, Mar 21, 2006 at 12:08:47PM +0300, Roman Kurakin wrote:
 > Eygene Ryabinkin:
 > 
 > >>Thats ipv4 specific, I am happy with this patch and it passes the test
 > >>on sparc64. Its similar to Eygene's patch but has the benifit of only
 > >>aligning if we are doing a bridge_pfil() and it only aligns the duped
 > >>packet so there is no performance hit on a 2 interface bridge.
 > >>
 > >>Can you test this Eygene?
 > >>   
 > >>
 > >Your patch is also fine: I see no corrupted packets. Looks like it is
 > >the final one. I will watch my bridge closely and will tell you if
 > >something will go wrong with this patch.
 > > 
 > >
 > Ok, I'll commit this patch to the current and lets it sit there a week 
 > before MFC-ing.
 
 Are you still doing this? please do :)
 
 Andrew
State-Changed-From-To: open->closed 
State-Changed-By: rik 
State-Changed-When: Mon Apr 3 07:52:28 UTC 2006 
State-Changed-Why:  
Patch has been commited. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=94448 
>Unformatted:
