kern/127053: Still bridge issues - with L2 protocols such as PPPoE
Helge Oldach
freebsd-bridge-sep08 at oldach.net
Tue Sep 2 21:30:04 UTC 2008
>Number: 127053
>Category: kern
>Synopsis: Still bridge issues - with L2 protocols such as PPPoE
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Sep 02 21:30:03 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator: Helge Oldach
>Release: FreeBSD 6.4-1330 i386
>Organization:
>Environment:
System: FreeBSD localhost 6.4-1330 FreeBSD 6.4-1330 #0: Tue Sep 2 18:34:28 CEST 2008 toor at localh
ost:/usr/obj/usr/src/sys/HMO i386
>Description:
Since the "MAC inheritance" change in if_bridge (SVN r180140) I observe
loss of connectivity due to ARP timeouts and also layer-2 connectivity
issues.
The change below (and the according MFCs) indeed fixes the ARP bridging
issue, but does not fix layer-2 protocols.
For instance, I run a bridge with a wi0 and an fxp0 interface, while
talking PPPoE over the fxp0 interface simultaneously. I observe that the
change below fixes my IP connectivity issue over the bridge, but PPPoE
is still broken. I still need to change the Ethernet address of bridge0
(disable inheritence of the bridge's MAC address from the first member
interface) to make it work.
So I would suggest that a true fix should be implemented in if_bridge,
not in the IP stack.
The issue applies identically to CURRENT, 7-STABLE and 6-STABLE.
Revision 1.174: download - view: text, markup, annotated - select for diffs
Mon Aug 18 09:06:11 2008 UTC (2 weeks, 1 day ago) by philip
Branches: MAIN
Diff to: previous 1.173: preferred, colored
Changes since revision 1.173: +24 -1 lines
SVN rev 181824 on 2008-08-18 09:06:11Z by philip
Fix ARP in bridging scenarios where the bridge shares its
MAC address with one of its members (see my r180140).
Pointy hat to: philip
Submitted by: Eygene Ryabinkin <rea-fbsd at codelabs.ru>
MFC after: 3 days
>How-To-Repeat:
Set up PPPoE over a bridge member interface...
>Fix:
Eygene supplied a patch that supposedly fixes this issue by introducing
a sysctl that makes the former if_bridge behaviour default, and which
must be turned on to enable MAC inheritance. I have not tested this
patch yet.
I wonder what the purpose of MAC inheritance is anyway... Multiple
unicast MACs in one segment sounds pretty odd.
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list