From nobody@FreeBSD.ORG Thu Oct  7 08:54:52 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id D6669158FE; Thu,  7 Oct 1999 08:54:33 -0700 (PDT)
Message-Id: <19991007155433.D6669158FE@hub.freebsd.org>
Date: Thu,  7 Oct 1999 08:54:33 -0700 (PDT)
From: santa@sitara.net
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: bridge forwarding corrupted broadcast IP packets
X-Send-Pr-Version: www-1.0

>Number:         14183
>Category:       kern
>Synopsis:       bridge forwarding corrupted broadcast IP packets
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    grog
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct  7 09:00:01 PDT 1999
>Closed-Date:    Sat Feb 17 12:58:36 PST 2001
>Last-Modified:  Sat Feb 17 13:00:30 PST 2001
>Originator:     Santa Wiryaman
>Release:        3.2-RELEASE
>Organization:
Sitara Networks, Inc.
>Environment:
FreeBSD 3.2-RELEASE i386,
options BRIDGE, and 
sysctl -w net.link.ether.bridge=1
>Description:

Upon receiving broadcast IP packets, such as DHCP or ping 10.1.2.255
packets, the bridge frequently forwards the packets with the ip_len,
ip_id, and ip_off fields in host order.

The problem is because the received packet is store in an mbuf
cluster, and bdg_forward() (in net/bridge.c) calls m_copypacket() to
duplicate the mbuf cluster.  The copy of the mbuf goes out to an
outgoing interface, and the original mbuf up to the local IP stack.
Since m_copypacket() does not copy the external storage of the mbuf,
it is possible that the local IP stack modifies the external storage
while a copy of the mbuf is still pending in the interface output
queue.

The problem affects broadcast and multicast IP packets.  I noticed the
problem when DHCP address request operation works only intermittenly.
It would also affects the operations of RIP, etc.

>How-To-Repeat:

Configure a FreeBSD system with options BRIDGE.  Let it bridge between
two LAN segments.  On one side, have a system ping to the broadcast
address.  On the other side, run tcpdump.  Frequently tcpdump will
report a "truncated-ip" packet.  This is because the ip_len field is
not in network order.

>Fix:

Provide a function similar to m_copypacket() that allocates a new
external storage, rather than just referencing the external storage of
the source mbuf cluster.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->grog 
Responsible-Changed-By: grog 
Responsible-Changed-When: Tue Oct 26 13:52:09 PDT 1999 
Responsible-Changed-Why:  
grog is handling this PR. 
State-Changed-From-To: open->closed 
State-Changed-By: luigi 
State-Changed-When: Sat Feb 17 12:58:36 PST 2001 
State-Changed-Why:  
This specific problem was fixed around 3.3, 
and there have been massive fixes in the bridging code 
for STABLE and CURRENT in the last 2 weeks so these 
versions should be ok by now. 



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

Greg Lehey, 26 October 1999

     Message text reformatted to less than 80 characters.  This
     appears to be a problem with the web interface.

     I spoke to Santa about this problem.  He has a fix which works at
     Sitara on 3.2-RELEASE.  I shall commit it in the near future.
