lin john | 1 Feb 08:20 2009

RSTP support in linux kernel 2.6


  Is there source code and bridge utility available in
the Linux kernel 2.6.21 ?



Bridge mailing list
Bridge <at>
Stephen Hemminger | 2 Feb 19:15 2009

Re: RSTP support in linux kernel 2.6

On Sun, 1 Feb 2009 15:20:17 +0800 (CST)
lin john <johnlin2001 <at>> wrote:

> Hi,
>   Is there source code and bridge utility available in
> the Linux kernel 2.6.21 ?
>   Thanks
> John
> _______________________________________
>  辣茩妏蚚閉湮講捇誥蚘眊 

On current wiki

Current code is in GIT repositories:

Bridge utils
Bridge mailing list
Bridge <at>
Bernhard Weirich | 3 Feb 18:03 2009

RSTP problem after ifupdown


I'm using RSTP which is working most of the time, but there is one problem I ran into when I tried to reconfigure the bridge interface.

I have a bridge br0 with an interface eth0.
both are up and running,
then I do :
# ifconfig br0 down
br0: port 1(eth0) entering disabled state
# ifconfig br0 up

The strange thing is that eth0 is still up but the stp link is not reactivated from disabled to learning.
When I unplug eth0 and replug it the link enters learning and forwarding stages as usual.
So I assume that the kernel deactivates the link without the knowledge of the bridge, and so for the bridge there is no need to reactivate it.

Is this a problem just with my config or can someone else confirm this behaviour?

Bernhard Weirich
Bridge mailing list
Bridge <at>
Bernhard Weirich | 4 Feb 12:56 2009

Re: RSTP problem after ifupdown

I have fixed the problem for myself by adding some code to
Here is the patch...

Signed-off-by: Bernhard Weririch <bernhard.weirich <at>>
--- rstp-09-02/./bridge_track.c	2009-02-04 12:12:03.000000000 +0100
+++ rstp-09/./bridge_track.c 2009-02-04 11:59:48.000000000 +0100
 <at>  <at>  -72,6 +72,7  <at>  <at> 
 	/* If port */
 	int speed;
 	int duplex;
+	__u8 state;
 	struct ifdata *master;
 	struct ifdata *port_next;
 	/* STP port index */
 <at>  <at>  -403,12 +404,20  <at>  <at> 
 void set_br_up(struct ifdata *br, int up)
 	int stp_up = stp_enabled(br);
-	INFO("%s was %s stp was %s", br->name,up ? "up" : "down", br->stp_up ?
"up" : "down");
+	INFO("%s was %s stp was %s", br->name,br->up ? "up" : "down",
br->stp_up ? "up" : "down");
 	INFO("Set bridge %s %s stp %s" , br->name,
 	     up ? "up" : "down", stp_up ? "up" : "down");

-	if (up != br->up)
+	if (up != br->up) {
 		br->up = up;
+		if (br->up && br->stp_up && stp_up) {
+			struct ifdata *port = br->port_list;
+			for (port = br->port_list; port; port = port->next) {
+				if (port->up) 
+					bridge_set_state(port->if_index, port->state);
+			}
+		}
+	}
 	if (br->stp_up != stp_up) {
 		if (stp_up)
 <at>  <at>  -491,8 +500,10  <at>  <at> 
 			return -1;
 		/* Bridge must be up if we get such notifications */
-		if (!br->up)
-			set_br_up(br, 1);
+		/* bwe: in fact, the bridge gets the notifications even when down
+		 * therefore commented out */
+		//if (!br->up)
+		//	set_br_up(br, 1);

 	struct ifdata *ifc = find_if(if_index);
 <at>  <at>  -742,8 +753,10  <at>  <at> 
 		fprintf(stderr, "set_port_state: Unexpected state %d\n", state);
 		return -1;
-	if (port->up)
+	if (port->up) {
+		port->state = br_state;
 		bridge_set_state(port->if_index, br_state);
+	}
 	return 0;
David Ames | 3 Feb 18:04 2009

New beta CMS for

We are about to launch our public beta content management system. We wanted to address our work groups first
to give you the opportunity to have first access and update content in the new CMS.

Log into with your LF account. The same
account you used for wiki.

Click on your respective group and then click Join or Request Membership from the right hand menu options. I
will respond to these requests ASAP. Please send me an email if you should be the manager of the group. The
manager can decide how the group is configured and handles membership requests. 

Groups can be in one of the following configurations:
 Open - membership requests are accepted immediately.
 Moderated - membership requests must be approved.
 Invite only - membership must be created by an administrator.
 Closed - membership is exclusively managed by an administrator. 

The primary content type to utilize for work group content is "Group wiki" this content type will be
associated with your group and can be edited by all group members. You can create this content type by
clicking on "Create Content in the upper right or Create Group wiki page in the right hand menu.

If your group has not yet been created, please let me know and I will get it setup.

I have attached our public beta release notification for further details.

David Ames
The Linux Foundation
david <at>

    Hello Linux Foundation Community,

    In February 2009, the Linux Foundation (LF) will release to the public a new beta content management system
that will support improved publishing, membership acquisition, workgroup management, and content
management using the open source Drupal 6 as our Content Management System (CMS) of choice.  The goal of the
implementation is to develop a long-term comprehensive CMS solution that will support the growth and
sustainability of the foundation's goals, strategies, and growth. The new system will integrate with
other LF workgroup and publishing sites.

    The intention of this communication is that no stakeholder in the new CMS implementation process be
surprised by the content of the beta system, or by the identification of the alternative legacy data that
resides in the Wiki. This will be achieved through a multi-step release strategy in which the release
process is conducted in a manner that stakeholders have input, and ample time to migrate their respective
information into the new system.

    The advantage of this approach is that all stakeholders will have an opportunity to make their data
up-to-date and only migrate what is relavant and known during the process. The LF web team will assist and
provide technical know-how, training , and support as necessary for the stakeholder to input their
workgroup information prior to the public release of the new site, and thereafter. A disadvantage of this
approach, however, lies in the possibility that stakeholders may or may not have their entire
documentation migrated to the new site prior to launch. The LF web team is aware of this issue, and
therefore will keep the old MediaWiki site and data up and accessable by web browsing and search as long as
possible to support workgroup migration to the new CMS. Unfortunately, some URLs will change as a result
of migration to the new system.

    New CMS Benefits!

        * Implement robust content management system
        * Focus on branding, usability, and SEO of content
        * Replace one-off home grown templates and disparate websites wherever possible
        * Workgroups have better control of content, and access to content
        * Make it easier for the Linux community to use/reuse the Linux Foundation content

    What now?

        * The web team is readying Phase 1 roll out of the beta site for February 4, 2009
        * Contact Dan Lopez (dlopez <at> or Craig Ross (ccr <at> to
acknowledge and coordinate migration action items for respective content
        * Review current staging area and content for your workgroup
        * Attend training for the new system on [Date TBD]

    Action Items: 
    1. Please migrate your existing content from the existing LF site to by
February 6, 2009.
    It's important that content that the public should easily be able to navigate be moved. If you have content
that is not up to date, you can simply leave on MediaWiki site and the LF will continue to maintain it at Please do not create new content on the old site.

    2. If you are a workgroup lead, please create a group, invite people, and start building your community on
the new site. To coordinate group creation please contact David Ames (david <at> no
later than February 4, 2009. If you do not do this in a timely fashion your workgroup may not make it to the
launch of the site and will have to go up after the site has launched.

    3. Any new content you'd like to create for your workgroup should be created in the new beta site after
February 4, 2009. If you need assistance in getting content created prior to receiving training, please
contact Dan (dlopez <at> or Craig  (ccr <at>

    Your existing LF accounts will work in the new system. You will also be able to login to your MediaWiki
account with the same account to retrieve other information that you mave have stored there.

    4. A training session for all interested parties on the new site will be held on [Date TBD] at 1pm-3pm PST. For
questions or feedback on the site, please email webteam <at> Taining is not mandatory
but is highly recommended.

    Phase I - Process Steps to Rollout Summary

        * Implement Drupal CMS
        * Content migration - first pass
        * Delegate content authors and owners to LF workgroups
        * Workgroups to schedule training with web team
        * Workgroup content migration - second pass
        * Go-Live

    Delegation of Ownership

        * Workgroup ownership of content
        * Web team ownership of CMS system administration and support
        * Web team ownership of branding, look and feel, and implementation
        * Workgroups to coordinate with web team about proper permissions and roles per workgroup

    Go Live!

        * Deadline for completion of content migration Phase 1 is February 6 2009
        * Old site will remain up throughout this process, and old data will be available
        * Flip the switch on February 2-6 2009 with public PR campaigns announcing the new site following week
        * All new content should be created in the new public beta release of the Drupal CMS system at February 9, 2009 onward. By March 1 the LF media wiki site will no longer
be write accessible, so it's imperative that you create a workgroup account on the new site if you wish to
create content on LF web properties.

    For questions, comments, or suggestions please contact:

    Amanda McPherson - amanda <at>

    Dan Lopez - dlopez <at>
Bridge mailing list
Bridge <at>
Jon Vincent | 6 Feb 08:20 2009

Query on RSTP application

I would want to use RSTP application on our switches. Im planning to use the RSTP implementation posted in: It would be helpful if someone would inform if there are patches applied over this implementation, as the last commit in the attachment stands at: 371cd560f79aa8da757d0fa6e8a279c42472b115 (Apr-1 '08).


Bridge mailing list
Bridge <at>
Srinivas M.A. | 8 Feb 06:08 2009

Re: Query on RSTP application

I have added a couple of fixes after that (which were pointed out on
this list). A tarball including git history is at:

On Fri, Feb 6, 2009 at 12:50 PM, Jon Vincent <jon.bvincent <at>> wrote:
> Hi,
> I would want to use RSTP application on our switches. Im planning to use the
> RSTP implementation posted in:
> It
> would be helpful if someone would inform if there are patches applied over
> this implementation, as the last commit in the attachment stands at:
> 371cd560f79aa8da757d0fa6e8a279c42472b115 (Apr-1 '08).
> Thanks,
> Jon
Bob O'Neil | 10 Feb 13:51 2009

Linux Advice on Controlled Bridge based on MAC Address with Delay and Dropout

How to I leverage what is available on the Linux Communcations Stack, either as part of the kernel itself  (i.e. ebtables, netbridge, tcc, iptables, etc.) and/or an addon module , that
allows me to implement a Linux Bridge, with the additional requirement of dropping out Ethernet frames (not bytes) based on a soft setting, and delaying frames (from 4 ms to 10 ms in 1 ms increments) in ONE direction only of the bridge?    This is for a i386 machine with 2 NICS that will need to be in promiscuous mode.
I am trying to determine the best course of action for an application/script that I need to
compose for execution under Red Hat Linux AS 4.0, Linux Kernel v2.6.x.
I have a 386 based Linux machine with two NICs that acts a bit like a bridge, dispatching frames
at the Data Link Layer (not IP, Layer 3).   On the ingress of NIC 1 (eth0), there will be certain
frames which have matching MACs that will be consumed (i.e. passed up the stack).   Other frames,
with a range of matching MAC addresses, broadcast and multicast need to be bridged to the other
NIC (call it NIC 2, or eth1).     Broadcast and Multicast also need to be consumed, so may have
two destinations, bridged between NICs and consumed from the internal stack.   I will need to assign
an IP address to the application so that it may act as an SNMP agent.
The converse direction follows a similar pattern based on the MAC address, certain frames
matching a range of MAC address will be bridged to NIC 1 from NIC 2, ones which match the MAC
address of NIC 2 will be consumed, broadcast and multicast need to be both consumed and forwarded
to the egress of NIC 1.
The assignments of the IPs, subnets, and subnet masks is flexible.

Now here is the complication that deviates from standard Linux kernel behavior.   ONLY for frames forwarded/bridged from
NIC 1 to NIC2, there are two soft settings that dictate the forwarding behavior:
1. Delay - this may range from say 4 ms to 15 ms.   Based on this setting, ingress frames on NIC 1
that will be forwarded on to NIC 2 need to be delayed in the process.   The delay timing needs to
be fairly precise, to the millisecond if possible, and possibly as low as 4 ms.
2. Drop Out Percentage - ranges from 0 to 100%.   Based on this setting, ingress frames on NIC 1
will be dropped based on the percentage set.   The dropout could be a simple uniform dropout, so that if
the percentage is set to 25%, 1 in 4 frames will be dropped.
Ethernet frames forwarded in the opposite direction (eth1 to eth0) do not have to be delayed or dropped.

I am trying to come up with a design that is optimum, and that takes maximum advantage of what is
available in the Linux kernel (via NetFilter/IPTables/EBTables/TCC/bctrl, etc.) via commands.

To slow down outgoing traffic, the Tunnel Bucket Filter (TBF) seems like a possible command line
solution for the delay requirement.   However, of particular concern is the fact that it is byte based
rather than frame based, and it appears it may not guarantee a uniform pacing of frames to the
user specified delay value with fidelity.   In addition, from the document entitled "Linux Advanced Routing & Traffic Control HOWTO",
is the quote:

"However, due to the default 10ms timer resolution of Unix, with 10.000 bits average packets, we
are limited to 1mbit/s of peakrate!"
This statement seems to suggest that the maximum precision for a delay would come at 10 ms
increments, and it is not clear if a low value, say 4 ms would be possible.
For the dropout requirement, perhaps some form of Random Early Drops, although the dropping needs
to be percise according to a fixed percentage.   The dropping needs to be based probably on frames rather than bytes.
I am considering solutions composed of scripting of the Linux kernel to do all the work entirely, or hybrid approach
as required to supplement the Linux kernel with user code as required.

I considered using the IPTABLES -j QUEUE method to queue contents matching a MAC address range to
user land queues, where they would programatically be dropped or delayed.  Perhaps a better fit would be
EPTables that deals with Ethernet frames,  However, it would seem these might be problematic for frames
which have two destinations,  such as broadcast and multicast, which need to be both left on the internal stack and
forwarded/bridged to the other NIC.
Whereas a pure bridge forwards on all content, I also need to maintain an SMNP agent, which will require that frames
matching the IP assigned to the bridge are allowed to pass up the stack for internal consumption.    Forwarding will
also be limited to a range of MAC addresses.   Both NICs will need to operate in promiscuous mode.
It is not entirely clear whether or not I can do bridging (brctl) in combination with ebtables/netfilter/iptables/tcc.
I may to implement some form of the Spanning Tree Protocol (STP), and perhaps DHCP to establish the IP for
the pseudo-bridge.

The lowest level alternative that I have considered, the one with the highest level of control but possible
the most custom coding, is using the  PCAPS (libpcap) frame sniffer technology based on the low level NDIS driver,
which allows me to get a callback into user land for each frame received by the NIC in promiscuous mode.   Using
this approach, I would queue or drop frames in a userland application, and then bridge/forward
them on to the other NIC based on a custom scheduler thread.   This would require me to queue the
frames in user land, but provides the highest level of control, and perhaps the fastest
forwarding as I would read from one NIC and bridge to the other.   I would also leave the frame
on the stack so it could have two destinations.  This technique would allow me to delay frames with a fairly
fine grain of precision, but does not take maximum advantage of the services already provided by the Linux
Interested in what design approach you think will fulfil my goals.   Any direction you can point
me in would be most appreciated.
Bob O'Neil
Bridge mailing list
Bridge <at> | 15 Feb 13:22 2009

Two bridge and STP

Hello, my LAN today has this topology:


[bridge] is a Linux box with 3 NIC, 2 of them are a bridge (br0) with IPtables 
for firewalling. The other nic is for management.

I want to have a standby 
backup for [bridge] in case of failure. I've read some documentation and I came 
in conclusion that the new topoligy will be:


      |           |
 [bridge]   [bridge2]
      |           |


with the two bridges STP enabled.

I think I had to:

install bridge2 configured as bridge
- rsync firewall rules between the two 
- enable STP protocol on both bridges
- assign a lower STP priority to 
[bridge] to became master
-... enjoy?

Are my assumpions correct?
Henk Stegeman | 18 Feb 11:41 2009

net_device_ops support in bridging and fec_mpc52xx.c


I discovered the hard way that because linux bridging uses
net_device_ops, bridging only works with network drivers that publish
their device operations trough net_device_ops.

In my case running:

brctl addif br0 eth0 (where eth0 fec_mpc52xx.c did not yet support
net_device_ops) gave me a:

Unable to handle kernel paging request...

After changing fec_mpc52xx.c to support net_device_ops the problem was fixed.

If possible some kind of detection in the bridging software is i think
mostly appreciated for early detection of this problem, as it is
pretty hard to relate the error message to a not updated driver.



diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cd8e98b..a2841eb 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
 <at>  <at>  -888,6 +888,22  <at>  <at>  static int mpc52xx_fec_ioctl(struct net_device
*dev, struct ifreq *rq, int cmd)
 /* ======================================================================== */
 /* OF Driver                                                                */
 /* ======================================================================== */
+static const struct net_device_ops mpc52xx_fec_netdev_ops = {
+       .ndo_open               = mpc52xx_fec_open,
+       .ndo_stop               = mpc52xx_fec_close,
+       .ndo_start_xmit         = mpc52xx_fec_hard_start_xmit,
+       .ndo_tx_timeout         = mpc52xx_fec_tx_timeout,
+       .ndo_get_stats          = mpc52xx_fec_get_stats,
+       .ndo_set_multicast_list = mpc52xx_fec_set_multicast_list,
+       .ndo_validate_addr      = eth_validate_addr,
+       .ndo_set_mac_address    = mpc52xx_fec_set_mac_address,
+       .ndo_do_ioctl           = mpc52xx_fec_ioctl,
+       .ndo_poll_controller     = mpc52xx_fec_poll_controller,

 static int __devinit
 mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
 <at>  <at>  -929,20 +945,7  <at>  <at>  mpc52xx_fec_probe(struct of_device *op, const
struct of_device_id *match)
 		return -EBUSY;

 	/* Init ether ndev with what we have */
-	ndev->open		= mpc52xx_fec_open;
-	ndev->stop		= mpc52xx_fec_close;
-	ndev->hard_start_xmit	= mpc52xx_fec_hard_start_xmit;
-	ndev->do_ioctl		= mpc52xx_fec_ioctl;
-	ndev->ethtool_ops	= &mpc52xx_fec_ethtool_ops;
-	ndev->get_stats		= mpc52xx_fec_get_stats;
-	ndev->set_mac_address	= mpc52xx_fec_set_mac_address;
-	ndev->set_multicast_list = mpc52xx_fec_set_multicast_list;
-	ndev->tx_timeout	= mpc52xx_fec_tx_timeout;
-	ndev->watchdog_timeo	= FEC_WATCHDOG_TIMEOUT;
-	ndev->base_addr		= mem.start;
-	ndev->poll_controller = mpc52xx_fec_poll_controller;
+	ndev->netdev_ops = &mpc52xx_fec_netdev_ops;

 	priv->t_irq = priv->r_irq = ndev->irq = NO_IRQ; /* IRQ are free for now */