Date: Thu, 7 Oct 1999 08:54:33 -0700 (PDT) From: santa@sitara.net To: freebsd-gnats-submit@freebsd.org Subject: kern/14183: bridge forwarding corrupted broadcast IP packets Message-ID: <19991007155433.D6669158FE@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 14183 >Category: kern >Synopsis: bridge forwarding corrupted broadcast IP packets >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 7 09:00:01 PDT 1999 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991007155433.D6669158FE>