Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

> -----Original Message-----
> From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> Sent: den 29 mars 2008 17:22
> To: 'Bridge@lists.linux-foundation.org'
> Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> 
> Hi List
> 
> I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> in on my 2.6.23 kernel, but didn't get very far:
> 
> Created a bridge, br0, with brctl and added two interfaces.
> started rstpd without args and ran rstpctl
>   rstpctl showbridge br0
> and all I get is
>   CTL_get_bridge_state: Got return code 0, 1003
>   Failed to get bridge state: Err_Bridge_is_down
> 
> The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> I probably forgot to do something I suppose, but what?
> 
>     Jocke

Never mind, user error on my part.

I do wonder though if rstpd is production ready or still needs more
testing/fixes?

   Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Stephen Hemminger]

On Sat, 29 Mar 2008 18:10:24 +0100
"Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:

> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > Sent: den 29 mars 2008 17:22
> > To: 'Bridge@lists.linux-foundation.org'
> > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> > 
> > Hi List
> > 
> > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> > in on my 2.6.23 kernel, but didn't get very far:
> > 
> > Created a bridge, br0, with brctl and added two interfaces.
> > started rstpd without args and ran rstpctl
> >   rstpctl showbridge br0
> > and all I get is
> >   CTL_get_bridge_state: Got return code 0, 1003
> >   Failed to get bridge state: Err_Bridge_is_down
> > 
> > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> > I probably forgot to do something I suppose, but what?
> > 
> >     Jocke
> 
> Never mind, user error on my part.
> 
> I do wonder though if rstpd is production ready or still needs more
> testing/fixes?
> 
>    Jocke

The rstpd stuff isn't widely used, more because of the administration,
packaging, startup issues etc. It is kind of a chicken/egg problem, no
one uses it so no one reports bugs.The RSTP code library has been
around for a long while and doesn't have any known issues.

Since Vyatta is a debian based distribution, I am toying with the idea
of making a debian package for rstp to get more early users.
I recommend anyone making an appliance based distribution or device
consider using rstpd since the kernel STP code is so old.

After the rstpd code is more widely used, the kernel STP code should
be able to be fully disabled.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Mon, 2008-03-31 at 09:06 -0700, Stephen Hemminger wrote:
> On Sat, 29 Mar 2008 18:10:24 +0100
> "Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:
> 
> > > -----Original Message-----
> > > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > > Sent: den 29 mars 2008 17:22
> > > To: 'Bridge@lists.linux-foundation.org'
> > > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> > > 
> > > Hi List
> > > 
> > > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> > > in on my 2.6.23 kernel, but didn't get very far:
> > > 
> > > Created a bridge, br0, with brctl and added two interfaces.
> > > started rstpd without args and ran rstpctl
> > >   rstpctl showbridge br0
> > > and all I get is
> > >   CTL_get_bridge_state: Got return code 0, 1003
> > >   Failed to get bridge state: Err_Bridge_is_down
> > > 
> > > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> > > I probably forgot to do something I suppose, but what?
> > > 
> > >     Jocke
> > 
> > Never mind, user error on my part.
> > 
> > I do wonder though if rstpd is production ready or still needs more
> > testing/fixes?
> > 
> >    Jocke
> 
> The rstpd stuff isn't widely used, more because of the administration,
> packaging, startup issues etc. It is kind of a chicken/egg problem, no
> one uses it so no one reports bugs.The RSTP code library has been
> around for a long while and doesn't have any known issues.

I see, what do you think of Srinivas rewrite? I looks
much cleaner, have you had a chance to test it? 

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Stephen Hemminger]

On Mon, 31 Mar 2008 19:06:14 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> 
> On Mon, 2008-03-31 at 09:06 -0700, Stephen Hemminger wrote:
> > On Sat, 29 Mar 2008 18:10:24 +0100
> > "Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:
> > 
> > > > -----Original Message-----
> > > > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > > > Sent: den 29 mars 2008 17:22
> > > > To: 'Bridge@lists.linux-foundation.org'
> > > > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> > > > 
> > > > Hi List
> > > > 
> > > > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> > > > in on my 2.6.23 kernel, but didn't get very far:
> > > > 
> > > > Created a bridge, br0, with brctl and added two interfaces.
> > > > started rstpd without args and ran rstpctl
> > > >   rstpctl showbridge br0
> > > > and all I get is
> > > >   CTL_get_bridge_state: Got return code 0, 1003
> > > >   Failed to get bridge state: Err_Bridge_is_down
> > > > 
> > > > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> > > > I probably forgot to do something I suppose, but what?
> > > > 
> > > >     Jocke
> > > 
> > > Never mind, user error on my part.
> > > 
> > > I do wonder though if rstpd is production ready or still needs more
> > > testing/fixes?
> > > 
> > >    Jocke
> > 
> > The rstpd stuff isn't widely used, more because of the administration,
> > packaging, startup issues etc. It is kind of a chicken/egg problem, no
> > one uses it so no one reports bugs.The RSTP code library has been
> > around for a long while and doesn't have any known issues.
> 
> I see, what do you think of Srinivas rewrite? I looks
> much cleaner, have you had a chance to test it? 

He did most of the original rstp code, just haven't had chance to merge it.
Dirty secret, I don't use bridging normally, and have to go out of my way to setup
tests so that is part of the reason I don't merge things until they have settled.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: den 31 mars 2008 19:09
> To: joakim.tjernlund@transmode.se
> Cc: Bridge@lists.linux-foundation.org
> Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary
> problems
> 
> On Mon, 31 Mar 2008 19:06:14 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> 
> >
> > On Mon, 2008-03-31 at 09:06 -0700, Stephen Hemminger wrote:
> > > On Sat, 29 Mar 2008 18:10:24 +0100
> > > "Joakim Tjernlund" <Joakim.Tjernlund@transmode.se> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> > > > > Sent: den 29 mars 2008 17:22
> > > > > To: 'Bridge@lists.linux-foundation.org'
> > > > > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary
> problems
> > > > >
> > > > > Hi List
> > > > >
> > > > > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> > > > > in on my 2.6.23 kernel, but didn't get very far:
> > > > >
> > > > > Created a bridge, br0, with brctl and added two interfaces.
> > > > > started rstpd without args and ran rstpctl
> > > > >   rstpctl showbridge br0
> > > > > and all I get is
> > > > >   CTL_get_bridge_state: Got return code 0, 1003
> > > > >   Failed to get bridge state: Err_Bridge_is_down
> > > > >
> > > > > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> > > > > I probably forgot to do something I suppose, but what?
> > > > >
> > > > >     Jocke
> > > >
> > > > Never mind, user error on my part.
> > > >
> > > > I do wonder though if rstpd is production ready or still needs more
> > > > testing/fixes?
> > > >
> > > >    Jocke
> > >
> > > The rstpd stuff isn't widely used, more because of the administration,
> > > packaging, startup issues etc. It is kind of a chicken/egg problem, no
> > > one uses it so no one reports bugs.The RSTP code library has been
> > > around for a long while and doesn't have any known issues.
> >
> > I see, what do you think of Srinivas rewrite? I looks
> > much cleaner, have you had a chance to test it?
> 
> He did most of the original rstp code, just haven't had chance to merge it.
> Dirty secret, I don't use bridging normally, and have to go out of my way to setup
> tests so that is part of the reason I don't merge things until they have settled.

:), maybe you could add a testing branch where the new code could be?

One reason for lack of testing of RSTP is that it is hard to find. The
bridge homepage just mentions that there is ongoing work w.r.t RSTP

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]

Hi Joakim,

  Would you be interested in testing out a newer implementation that
we now have? This is
much closer to the 802.1D-2004 standard and has passed the UNH RSTP
protocol tests.
My updates have not yet made it to Stephen Hemminger's git repo, but I
am attaching a
a patch set on top of that, as well as a tarball of my git-repo with
the additional commits.

I don't know how the mailing list handles attachments, let me see anyway.

I am interested in seeing this used more, and I will be happy to
assist with any issues. Please
let me know how things go.

This is fairly new code, but it has gone through some testing and use.
One limitation
is that there is no mechanism to automatically restart or fall back to
kernel STP if the RSTP
daemon crashes. But it hasn't crashed lately in our testing.

Thanks.
Srinivas.

P.S.: One note on bridge-stp and general bridge startup.

We started out with needing an explicit rstpctl command to indicate
to the daemon that it needs to run RSTP on a bridge, which is why there is the
"exec /sbin/rstpctl rstp $bridge on ;;" (as you corrected in your patch.)

But now, the daemon is written to enable RSTP when it finds that the
kernel is treating the
bridge as RSTP (/sys/class/net/<bridge_name>/bridge/stp_state is 2),
so as long as you run
"brctl stp <bridge_name> on" before briding the bridge interface up,
you can just have a
bridge-stp script that returns 0 (success) when you want rstpd to
handle the bridge, and
non-zero when you want kernel STP running on the bridge.

That startup sequence we use is:
0. Have a bridge-stp that returns 0 if you want RSTP for the
particular bridge name.
    Or returns 0 always if you intend to have only one bridge, and want RSTP.

1. Start rstpd
2. Configure the bridge (brctl addbr, brctl addif's ...)
3. brctl stp <bridge_name> on
4. ifconfig <bridge_name> up. (Or ifup <bridge_name>, which should
apply any IP config.)


On Sat, Mar 29, 2008 at 10:40 PM, Joakim Tjernlund
<Joakim.Tjernlund@transmode.se> wrote:
> > -----Original Message-----
>  > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
>  > Sent: den 29 mars 2008 17:22
>  > To: 'Bridge@lists.linux-foundation.org'
>  > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
>  >
>  > Hi List
>  >
>  > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
>  > in on my 2.6.23 kernel, but didn't get very far:
>  >
>  > Created a bridge, br0, with brctl and added two interfaces.
>  > started rstpd without args and ran rstpctl
>  >   rstpctl showbridge br0
>  > and all I get is
>  >   CTL_get_bridge_state: Got return code 0, 1003
>  >   Failed to get bridge state: Err_Bridge_is_down
>  >
>  > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
>  > I probably forgot to do something I suppose, but what?
>  >
>  >     Jocke
>
>  Never mind, user error on my part.
>
>  I do wonder though if rstpd is production ready or still needs more
>  testing/fixes?
>
>
>
>    Jocke
>
>  _______________________________________________
>  Bridge mailing list
>  Bridge@lists.linux-foundation.org
>  https://lists.linux-foundation.org/mailman/listinfo/bridge
>

[-- Attachment #2: rstp_patch.gz --]
[-- Type: application/x-gzip, Size: 113648 bytes --]

[-- Attachment #3: rstp.tgz --]
[-- Type: application/x-gzip, Size: 397900 bytes --]

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

Hi Srinivas

On Sun, 2008-03-30 at 15:02 +0530, Srinivas M.A. wrote:
> Hi Joakim,
> 
>   Would you be interested in testing out a newer implementation that
> we now have? This is
> much closer to the 802.1D-2004 standard and has passed the UNH RSTP
> protocol tests.

Sure am interested, thanks for the offer.

> My updates have not yet made it to Stephen Hemminger's git repo, but I
> am attaching a

Any time frame when this will hit Hemminger's repo?

> a patch set on top of that, as well as a tarball of my git-repo with
> the additional commits.

OK, will use your repo to begin with.

> 
> I don't know how the mailing list handles attachments, let me see anyway.

Got both of them.

> 
> I am interested in seeing this used more, and I will be happy to
> assist with any issues. Please
> let me know how things go.
> 
> This is fairly new code, but it has gone through some testing and use.
> One limitation
> is that there is no mechanism to automatically restart or fall back to
> kernel STP if the RSTP
> daemon crashes. But it hasn't crashed lately in our testing.

:) lets see, the lab here tends to create some really funny loops, often
by mistake.

> 
> Thanks.
> Srinivas.
> 
> P.S.: One note on bridge-stp and general bridge startup.
> 
> We started out with needing an explicit rstpctl command to indicate
> to the daemon that it needs to run RSTP on a bridge, which is why there is the
> "exec /sbin/rstpctl rstp $bridge on ;;" (as you corrected in your patch.)
> 
> But now, the daemon is written to enable RSTP when it finds that the
> kernel is treating the
> bridge as RSTP (/sys/class/net/<bridge_name>/bridge/stp_state is 2),
> so as long as you run
> "brctl stp <bridge_name> on" before briding the bridge interface up,
> you can just have a
> bridge-stp script that returns 0 (success) when you want rstpd to
> handle the bridge, and
> non-zero when you want kernel STP running on the bridge.
> 
> That startup sequence we use is:
> 0. Have a bridge-stp that returns 0 if you want RSTP for the
> particular bridge name.
>     Or returns 0 always if you intend to have only one bridge, and want RSTP.
> 
> 1. Start rstpd
> 2. Configure the bridge (brctl addbr, brctl addif's ...)
> 3. brctl stp <bridge_name> on
> 4. ifconfig <bridge_name> up. (Or ifup <bridge_name>, which should
> apply any IP config.)

OK, will, hopefully, try this this week. Today the girls got a new pet
and they are all over the place :)

 Jocke

> 
> 
> On Sat, Mar 29, 2008 at 10:40 PM, Joakim Tjernlund
> <Joakim.Tjernlund@transmode.se> wrote:
> > > -----Original Message-----
> >  > From: Joakim Tjernlund [mailto:Joakim.Tjernlund@transmode.se]
> >  > Sent: den 29 mars 2008 17:22
> >  > To: 'Bridge@lists.linux-foundation.org'
> >  > Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problems
> >  >
> >  > Hi List
> >  >
> >  > I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
> >  > in on my 2.6.23 kernel, but didn't get very far:
> >  >
> >  > Created a bridge, br0, with brctl and added two interfaces.
> >  > started rstpd without args and ran rstpctl
> >  >   rstpctl showbridge br0
> >  > and all I get is
> >  >   CTL_get_bridge_state: Got return code 0, 1003
> >  >   Failed to get bridge state: Err_Bridge_is_down
> >  >
> >  > The br0 i/f is UP amd RUNNING and so is the interfaces I added.
> >  > I probably forgot to do something I suppose, but what?
> >  >
> >  >     Jocke
> >
> >  Never mind, user error on my part.
> >
> >  I do wonder though if rstpd is production ready or still needs more
> >  testing/fixes?
> >
> >
> >
> >    Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>  > My updates have not yet made it to Stephen Hemminger's git repo, but I
>  > am attaching a
>
>  Any time frame when this will hit Hemminger's repo?

I sent the patches to him some time back, but perhaps he hasn't had
time to look over them. It is a large set of changes anyway.

>
>  :) lets see, the lab here tends to create some really funny loops, often
>  by mistake.

Once the rstp has started fine, things should generally be okay.
Please try it out and let me know.

Srinivas

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Sun, 2008-03-30 at 17:05 +0530, Srinivas M.A. wrote:
> >  > My updates have not yet made it to Stephen Hemminger's git repo, but I
> >  > am attaching a
> >
> >  Any time frame when this will hit Hemminger's repo?
> 
> I sent the patches to him some time back, but perhaps he hasn't had
> time to look over them. It is a large set of changes anyway.
> 
> >
> >  :) lets see, the lab here tends to create some really funny loops, often
> >  by mistake.
> 
> Once the rstp has started fine, things should generally be okay.
> Please try it out and let me know.
> 
> Srinivas

With my cross gcc, 3.4.6 I get:
rstp.c: In function `txConfig':
rstp.c:1185: warning: implicit declaration of function
`__builtin_offsetof'
rstp.c:1185: error: syntax error before "RawBPDU"
rstp.c: In function `txRstp':
rstp.c:1221: error: syntax error before "RawBPDU"
rstp.c: In function `txTcn':
rstp.c:1234: error: syntax error before "RawBPDU"

Seems like __builtin_offsetof isn't defined in gcc 3.4.6,
can do something about that?

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Sun, 2008-03-30 at 14:03 +0200, Joakim Tjernlund wrote:
> On Sun, 2008-03-30 at 17:05 +0530, Srinivas M.A. wrote:
> > >  > My updates have not yet made it to Stephen Hemminger's git repo, but I
> > >  > am attaching a
> > >
> > >  Any time frame when this will hit Hemminger's repo?
> > 
> > I sent the patches to him some time back, but perhaps he hasn't had
> > time to look over them. It is a large set of changes anyway.
> > 
> > >
> > >  :) lets see, the lab here tends to create some really funny loops, often
> > >  by mistake.
> > 
> > Once the rstp has started fine, things should generally be okay.
> > Please try it out and let me know.
> > 
> > Srinivas
> 
> With my cross gcc, 3.4.6 I get:
> rstp.c: In function `txConfig':
> rstp.c:1185: warning: implicit declaration of function
> `__builtin_offsetof'
> rstp.c:1185: error: syntax error before "RawBPDU"
> rstp.c: In function `txRstp':
> rstp.c:1221: error: syntax error before "RawBPDU"
> rstp.c: In function `txTcn':
> rstp.c:1234: error: syntax error before "RawBPDU"
> 
> Seems like __builtin_offsetof isn't defined in gcc 3.4.6,
> can do something about that?

ehh, that was easy to fix.

I do this
./rstpd
brctl addbr br0
brctl addif br0 eth0
brctl stp br0 on
ifconfig eth0 0.0.0.0 up
ifconfig br0  0.0.0.0 up
./rstpctl showbridge

br0
 enabled                  no
 bridge id              8000.002234567778
 designated root        0000.000000000000
 root port                 0                    path cost                  0
 max age                   0                    bridge max age            20
 hello time                0                    bridge hello time          2
 forward delay             0                    bridge forward delay      15
 tx hold count             6
 protocol version          2
 time since topology change      354
 toplogy change count              0
 topology change                  no

It does not get enabled and 
#> cat /sys/class/net/br0/bridge/stp_state
1

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Sun, 2008-03-30 at 14:19 +0200, Joakim Tjernlund wrote:
> On Sun, 2008-03-30 at 14:03 +0200, Joakim Tjernlund wrote:
> > On Sun, 2008-03-30 at 17:05 +0530, Srinivas M.A. wrote:
> > > >  > My updates have not yet made it to Stephen Hemminger's git repo, but I
> > > >  > am attaching a
> > > >
> > > >  Any time frame when this will hit Hemminger's repo?
> > > 
> > > I sent the patches to him some time back, but perhaps he hasn't had
> > > time to look over them. It is a large set of changes anyway.
> > > 
> > > >
> > > >  :) lets see, the lab here tends to create some really funny loops, often
> > > >  by mistake.
> > > 
> > > Once the rstp has started fine, things should generally be okay.
> > > Please try it out and let me know.
> > > 
> > > Srinivas
> > 
> > With my cross gcc, 3.4.6 I get:
> > rstp.c: In function `txConfig':
> > rstp.c:1185: warning: implicit declaration of function
> > `__builtin_offsetof'
> > rstp.c:1185: error: syntax error before "RawBPDU"
> > rstp.c: In function `txRstp':
> > rstp.c:1221: error: syntax error before "RawBPDU"
> > rstp.c: In function `txTcn':
> > rstp.c:1234: error: syntax error before "RawBPDU"
> > 
> > Seems like __builtin_offsetof isn't defined in gcc 3.4.6,
> > can do something about that?
> 
> ehh, that was easy to fix.
> 
> I do this
> ./rstpd
> brctl addbr br0
> brctl addif br0 eth0
> brctl stp br0 on
> ifconfig eth0 0.0.0.0 up
> ifconfig br0  0.0.0.0 up
> ./rstpctl showbridge
> 
> br0
>  enabled                  no
>  bridge id              8000.002234567778
>  designated root        0000.000000000000
>  root port                 0                    path cost                  0
>  max age                   0                    bridge max age            20
>  hello time                0                    bridge hello time          2
>  forward delay             0                    bridge forward delay      15
>  tx hold count             6
>  protocol version          2
>  time since topology change      354
>  toplogy change count              0
>  topology change                  no
> 
> It does not get enabled and 
> #> cat /sys/class/net/br0/bridge/stp_state
> 1

Have this code been tested on a big endian CPU?

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

> -----Original Message-----
> From: Srinivas M.A. [mailto:srinivas.aji@gmail.com]
> Sent: den 30 mars 2008 11:32
> To: Joakim Tjernlund
> Cc: Bridge@lists.linux-foundation.org
> Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary
> problems
> 
> This is fairly new code, but it has gone through some testing and use.
> One limitation
> is that there is no mechanism to automatically restart or fall back to
> kernel STP if the RSTP
> daemon crashes. But it hasn't crashed lately in our testing.

Should be fixable, just vfork and wait for an abnormal exit status,
reset state and vfork again.

> 
> Thanks.
> Srinivas.
> 
> P.S.: One note on bridge-stp and general bridge startup.
> 
> We started out with needing an explicit rstpctl command to indicate
> to the daemon that it needs to run RSTP on a bridge, which is why there is the
> "exec /sbin/rstpctl rstp $bridge on ;;" (as you corrected in your patch.)
> 
> But now, the daemon is written to enable RSTP when it finds that the
> kernel is treating the
> bridge as RSTP (/sys/class/net/<bridge_name>/bridge/stp_state is 2),

hmm, how does stp_state become 2? Do I need a new kernel(on 2.6.23 now)?

> so as long as you run
> "brctl stp <bridge_name> on" before briding the bridge interface up,
> you can just have a
> bridge-stp script that returns 0 (success) when you want rstpd to
> handle the bridge, and
> non-zero when you want kernel STP running on the bridge.
> 
> That startup sequence we use is:
> 0. Have a bridge-stp that returns 0 if you want RSTP for the
> particular bridge name.
>     Or returns 0 always if you intend to have only one bridge, and want RSTP.

Don't follow, why do I need a bridge-stp at all? Seem like I should
just start rstpd and config my bridge normally?

> 
> 1. Start rstpd
> 2. Configure the bridge (brctl addbr, brctl addif's ...)
> 3. brctl stp <bridge_name> on
> 4. ifconfig <bridge_name> up. (Or ifup <bridge_name>, which should
> apply any IP config.)

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>  > One limitation
>  > is that there is no mechanism to automatically restart or fall back to
>  > kernel STP if the RSTP
>  > daemon crashes. But it hasn't crashed lately in our testing.
>
>  Should be fixable, just vfork and wait for an abnormal exit status,
>  reset state and vfork again.

Yes, doable, not yet done though.

>  hmm, how does stp_state become 2? Do I need a new kernel(on 2.6.23 now)?

>  Don't follow, why do I need a bridge-stp at all? Seem like I should
>  just start rstpd and config my bridge normally?

2.6.23 has all the kernel stuff needed.

The way things happen is this:

When you do "brctl stp <bridge_name> on", the kernel runs
"/sbin/bridge-stp <bridge_name> start" and waits for the exit code. If
the exit code is 0, the kernel sets stp_state to 2, and assumes that
userspace will take care of STP and does not do any STP actions. (This
state is different from STP disabled, since during STP disabled, the
kernel still brings up ports from learning to forwarding using a
timeout, and also, the bridge forwards BPDUs too in that state.) If
the exit code is non-zero, stp_state is set to 1 and kernel STP is
activated.

So you need to:
1. Start rstpd
2. Have a bridge-stp script that returns success
3. Configure your bridge. (Here, because of the event mechanism
currently available, it is best to do "brctl stp <bridge_name> on"
before doing "ifconfig <bridge_name> up")

> I do this
> ./rstpd
> brctl addbr br0
> brctl addif br0 eth0
> brctl stp br0 on
> ifconfig eth0 0.0.0.0 up
> ifconfig br0  0.0.0.0 up
> ./rstpctl showbridge

> It does not get enabled and
> #> cat /sys/class/net/br0/bridge/stp_state
> 1

This should have worked. Could you check that /sbin/bridge-stp has
execute bit set and is getting run? It doesn't have stdout, etc, so
you need to log messages to a file to see what is happening. e.g.
(date; echo $0 "$@") >>/tmp/bridge-stp.log

Also, rstp will log to syslog. To see lots more messages, you can do
"rstpctl debuglevel 4", but since we are doing
(main.c) vsyslog((level <= LOG_LEVEL_INFO) ? LOG_INFO : LOG_DEBUG, ....
you need to configure your syslog to log the LOG_DEBUG messages as
well to see them, or just fix the code to get all the messages at
LOG_INFO.

> Have this code been tested on a big endian CPU?

No, only ix86 and x86_64 at the moment. At least in the RSTP logic
itself (rstp.[ch]), I seem to have taken some care to use bytes
directly for the on-the-wire structures and convert to and from
numbers using arithmetic, which should be endian independent. I don't
see any obviously little endian specific code in the other parts
either. The rstpctl program relies on structures having the same
binary layout in it as well as in rstpd, but that should not be
affected by endianness.

In any case, see if you can get the bridge-stp thing working to the
point where you see stp_state as 2. If you see issues past that, like
received BPDU's not being recognized, or anything else seeming
endianness related, I will set up a qemu powerpc image and test.

Thanks.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Mon, 2008-03-31 at 00:43 +0530, Srinivas M.A. wrote:
> >  > One limitation
> >  > is that there is no mechanism to automatically restart or fall back to
> >  > kernel STP if the RSTP
> >  > daemon crashes. But it hasn't crashed lately in our testing.
> >
> >  Should be fixable, just vfork and wait for an abnormal exit status,
> >  reset state and vfork again.
> 
> Yes, doable, not yet done though.
> 
> >  hmm, how does stp_state become 2? Do I need a new kernel(on 2.6.23 now)?
> 
> >  Don't follow, why do I need a bridge-stp at all? Seem like I should
> >  just start rstpd and config my bridge normally?
> 
> 2.6.23 has all the kernel stuff needed.
> 
> The way things happen is this:
> 
> When you do "brctl stp <bridge_name> on", the kernel runs
> "/sbin/bridge-stp <bridge_name> start" and waits for the exit code. If
> the exit code is 0, the kernel sets stp_state to 2, and assumes that
> userspace will take care of STP and does not do any STP actions. (This
> state is different from STP disabled, since during STP disabled, the
> kernel still brings up ports from learning to forwarding using a
> timeout, and also, the bridge forwards BPDUs too in that state.) If
> the exit code is non-zero, stp_state is set to 1 and kernel STP is
> activated.
> 
> So you need to:
> 1. Start rstpd
> 2. Have a bridge-stp script that returns success
> 3. Configure your bridge. (Here, because of the event mechanism
> currently available, it is best to do "brctl stp <bridge_name> on"
> before doing "ifconfig <bridge_name> up")
> 
> > I do this
> > ./rstpd
> > brctl addbr br0
> > brctl addif br0 eth0
> > brctl stp br0 on
> > ifconfig eth0 0.0.0.0 up
> > ifconfig br0  0.0.0.0 up
> > ./rstpctl showbridge
> 
> > It does not get enabled and
> > #> cat /sys/class/net/br0/bridge/stp_state
> > 1
> 
> This should have worked. Could you check that /sbin/bridge-stp has
> execute bit set and is getting run? It doesn't have stdout, etc, so
> you need to log messages to a file to see what is happening. e.g.
> (date; echo $0 "$@") >>/tmp/bridge-stp.log

Ahh, I didn't copy bridge-stp to /sbin because I didn't think it was
needed. Just to test I blindly copied it to /sbin and did:
 brclt addbr br0
 brctl addif br0 eth0
 brctl stp br0
and it hung my board :(
So now I got to wait until I get to work. 
Not sure I like the dependancy on /sbin/bridge-stp hardcoded like that, but
for now it will do.

Meanwhile I got 2 patches for you:

From 152373da339f7ef2e71c696af1813e7425d83e79 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Sun, 30 Mar 2008 22:45:40 +0200
Subject: [PATCH] offsetof is defined in stddef.h, use that.


Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 rstp.c |    7 ++++---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/rstp.c b/rstp.c
index 7191778..b506373 100644
--- a/rstp.c
+++ b/rstp.c
@@ -29,6 +29,7 @@
 *********************************************************************/
 
 #include "rstp.h"
+#include <stddef.h>
 #include <string.h>
 
 /* Macros to be used in the later parts */
@@ -1144,9 +1145,9 @@ static void setTcPropTree(PORT_ARGS_PROTO)
 /***** txConfig(), txRstp() and txTcn() *****/
 
 /* To decide how much of the RawBPDU to actually transmit */
-#define offsetof(_TYPE, _MEMBER)  __builtin_offsetof (_TYPE, _MEMBER)
-//#define offsetof(_TYPE, _MEMBER) ((int)&((_TYPE *)0)->_MEMBER)
-
+#ifndef offsetof
+#define offsetof(_TYPE, _MEMBER) ((int)&((_TYPE *)0)->_MEMBER)
+#endif
 /* To fill the times values in the BPDU in txConfig() and txRstp() */
 
 static void set_bpdu_time(uchar time[2], int t)
-- 
1.5.4.3

From 14fc4be633e28e4ec7c1be7635e52f5ca44abc1b Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Sun, 30 Mar 2008 22:59:07 +0200
Subject: [PATCH] Replace gcc extension with C.


Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 rstp.c |   19 +++++++------------
 1 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/rstp.c b/rstp.c
index b506373..4db6074 100644
--- a/rstp.c
+++ b/rstp.c
@@ -43,22 +43,17 @@
 
 
 /* memcmp wrapper, validating size equality of _a and _b */
-#define CMP(_a, _op, _b)                                           \
-(memcmp(&(_a), &(_b),                                              \
-  __builtin_choose_expr(sizeof(_a) == sizeof(_b),                  \
-                        sizeof(_a),                                \
-                        (void)0)                                   \
-) _op 0)
+#define CMP(_a, _op, _b)					   \
+  (memcmp(&(_a), &(_b),						   \
+	  (sizeof(_a) == sizeof(_b) ?  sizeof(_a) : 0)		   \
+	  ) _op 0)
 
 #define ZERO(_a) memset(&(_a), 0, sizeof(_a))
 
 /* memcmp wrapper, validating size equality of _a and _b */
-#define CPY(_a, _b)                                           \
-(memcpy(&(_a), &(_b),                                              \
-  __builtin_choose_expr(sizeof(_a) == sizeof(_b),                  \
-                        sizeof(_a),                                \
-                        (void)0)                                   \
-))
+#define CPY(_a, _b)					      \
+  (memcpy(&(_a), &(_b),					      \
+	  (sizeof(_a) == sizeof(_b) ? sizeof(_a) : 0)))	      \
 
 #define BRIDGE_ARGS_PROTO        Bridge *BRIDGE
 #define PORT_ARGS_PROTO          Bridge *BRIDGE, Port *PORT
-- 
1.5.4.3

These are not tested as I manged to hang my board, stupid me beeing to impatient.

 Jocke

> 
> Also, rstp will log to syslog. To see lots more messages, you can do
> "rstpctl debuglevel 4", but since we are doing
> (main.c) vsyslog((level <= LOG_LEVEL_INFO) ? LOG_INFO : LOG_DEBUG, ....
> you need to configure your syslog to log the LOG_DEBUG messages as
> well to see them, or just fix the code to get all the messages at
> LOG_INFO.
> 
> > Have this code been tested on a big endian CPU?
> 
> No, only ix86 and x86_64 at the moment. At least in the RSTP logic
> itself (rstp.[ch]), I seem to have taken some care to use bytes
> directly for the on-the-wire structures and convert to and from
> numbers using arithmetic, which should be endian independent. I don't
> see any obviously little endian specific code in the other parts
> either. The rstpctl program relies on structures having the same
> binary layout in it as well as in rstpd, but that should not be
> affected by endianness.
> 
> In any case, see if you can get the bridge-stp thing working to the
> point where you see stp_state as 2. If you see issues past that, like
> received BPDU's not being recognized, or anything else seeming
> endianness related, I will set up a qemu powerpc image and test.
> 
> Thanks.
> 

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>
>  Ahh, I didn't copy bridge-stp to /sbin because I didn't think it was
>  needed. Just to test I blindly copied it to /sbin and did:
>   brclt addbr br0
>
>  brctl addif br0 eth0
>   brctl stp br0
>  and it hung my board :(

What did your /sbin/bridge-stp have. The file from the tarball? Try a
simple one which just does exit 0.

>  Meanwhile I got 2 patches for you:
>

I didn't realize offsetof() was in stddef.h. Thanks.

The __builtin_choose_expr stuff is there to trigger a compiler error
if I try to compare or copy two structs of different sizes. I should
just make that portion dependent on having a new enough gcc.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Mon, 2008-03-31 at 12:55 +0530, Srinivas M.A. wrote:
> >
> >  Ahh, I didn't copy bridge-stp to /sbin because I didn't think it was
> >  needed. Just to test I blindly copied it to /sbin and did:
> >   brclt addbr br0
> >
> >  brctl addif br0 eth0
> >   brctl stp br0
> >  and it hung my board :(
> 
> What did your /sbin/bridge-stp have. The file from the tarball? Try a
> simple one which just does exit 0.

Yes, form the tarball. Now I have replace it with a
  #!/bin/bash
  exit 0
and now it works(well it starts and activates RSTP) :)
So something isn't well with the included bridge-stp and
you can hang your system too.

Just for fun I tried what would happen if i never started rstpd,
then I get:

strace ./rstpctl showbridge
....
open("/dev/urandom", O_RDONLY)          = 3
read(3, "@\336\316\223", 4)             = 4
close(3)                                = 0
socket(PF_FILE, SOCK_DGRAM, 0)          = 3
getpid()                                = 245
bind(3, {sa_family=AF_FILE, path=@RSTPCTL_245}, 110) = 0
connect(3, {sa_family=AF_FILE, path=@.rstp_server}, 110) = -1
ECONNREFUSED (Connection refused)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 245 detached
root@192.168.1.16:~# m /sys/class/net/br0/bridge/stp_state
2

So I both get a SEGV and the kernel thinks userspace is running STP, not
ideal.

I really think one should be able to start RSTP with rtspctl too so
one doesn't need /sbin/bridge-stp

> 
> >  Meanwhile I got 2 patches for you:
> >
> 
> I didn't realize offsetof() was in stddef.h. Thanks.

I you want, you can remove the #ifndef too, gcc 3.4.6 has offsetof in
stddef.h

> 
> The __builtin_choose_expr stuff is there to trigger a compiler error
> if I try to compare or copy two structs of different sizes. I should
> just make that portion dependent on having a new enough gcc.

I removed it because I don't like having gcc extension in the code,
makes it dependend on gcc and harder to understand. gcc 3.4.6 can handle
this builtin fine.

 Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>
>  So I both get a SEGV and the kernel thinks userspace is running STP, not
>  ideal.

Segfault is fixed by this:

diff --git a/log.h b/log.h
index ce0d94e..2fcdcfb 100644
--- a/log.h
+++ b/log.h
@@ -63,7 +63,7 @@ extern int log_level;
 #ifdef NO_DAEMON

 #define ERROR(_fmt, _args...) \
-       PRINT(LOG_LEVEL_ERROR, "%s: " _fmt, ##_args)
+       PRINT(LOG_LEVEL_ERROR, "%s: " _fmt, __PRETTY_FUNCTION__, ##_args)

 #else
 #define ERROR(_fmt, _args...) \


>
>  I really think one should be able to start RSTP with rtspctl too so
>  one doesn't need /sbin/bridge-stp

bridge-stp is a way to tell the kernel whether it should run its STP
or not. This was set up to make it possible for users to run "brctl
stp <bridge_name> on" without directly being concerned with whether
kernel STP or userspace STP will be run.
But that doesn't really happen in practice I guess.

Unfortunately, bridge-stp is run with the kernel holding the RTNL
lock, so the set of things it can do without causing a hang is
limited. With the current kernel infrastructure, my preference would
be to start rstpd from the network init scripts in the system and use
bridge-stp just to decide whether to enable RSTP or kernel STP for the
given bridge, perhaps based on a setting in ifcfg-<bridge_name> (in
Redhat network config).

For more robustness, maybe we need additional kernel infrastructure
where the daemon can tell the kernel it will handle STP (this can be
done now by setting stp off and then on when bridge-stp will return
0), but where the kernel can also tell (maybe by polling) if the
daemon quits and fall back to kernel STP in that case.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

> -----Original Message-----
> From: Srinivas M.A. [mailto:srinivas.aji@gmail.com]
> Sent: den 31 mars 2008 19:00
> To: joakim.tjernlund@transmode.se
> Cc: Bridge@lists.linux-foundation.org
> Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary
> problems
> 
> >
> >  So I both get a SEGV and the kernel thinks userspace is running STP, not
> >  ideal.
> 
> Segfault is fixed by this:
> 
> diff --git a/log.h b/log.h
> index ce0d94e..2fcdcfb 100644
> --- a/log.h
> +++ b/log.h
> @@ -63,7 +63,7 @@ extern int log_level;
>  #ifdef NO_DAEMON
> 
>  #define ERROR(_fmt, _args...) \
> -       PRINT(LOG_LEVEL_ERROR, "%s: " _fmt, ##_args)
> +       PRINT(LOG_LEVEL_ERROR, "%s: " _fmt, __PRETTY_FUNCTION__, ##_args)
> 
>  #else
>  #define ERROR(_fmt, _args...) \

Thanks

> 
> 
> >
> >  I really think one should be able to start RSTP with rtspctl too so
> >  one doesn't need /sbin/bridge-stp
> 
> bridge-stp is a way to tell the kernel whether it should run its STP
> or not. This was set up to make it possible for users to run "brctl
> stp <bridge_name> on" without directly being concerned with whether
> kernel STP or userspace STP will be run.
> But that doesn't really happen in practice I guess.
> 
> Unfortunately, bridge-stp is run with the kernel holding the RTNL
> lock, so the set of things it can do without causing a hang is
> limited. With the current kernel infrastructure, my preference would
> be to start rstpd from the network init scripts in the system and use
> bridge-stp just to decide whether to enable RSTP or kernel STP for the
> given bridge, perhaps based on a setting in ifcfg-<bridge_name> (in
> Redhat network config).

I don't like the bridge-stp <bridge> start/stop interface. Why
would bridge-stp know what bridge to run RTSP on? A more natural
way, IMHO, would to extend brctl with a "rstp on" method. Why
is there one rstpctl tool and one brctl tool?

> 
> For more robustness, maybe we need additional kernel infrastructure
> where the daemon can tell the kernel it will handle STP (this can be
> done now by setting stp off and then on when bridge-stp will return
> 0), but where the kernel can also tell (maybe by polling) if the
> daemon quits and fall back to kernel STP in that case.

Yes, something is needed but I don't know the bride interface so I can't
really comment on how to do it.

    Jocke

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>
>  I don't like the bridge-stp <bridge> start/stop interface. Why
>  would bridge-stp know what bridge to run RTSP on? A more natural
>  way, IMHO, would to extend brctl with a "rstp on" method. Why
>  is there one rstpctl tool and one brctl tool?

I wrote rstpctl to just control the rstp daemon. Should integrate it
with brctl, making it so that brctl checks whether kernel STP or RSTP
is being used and sets either kernel STP config or sends the config to
rstpd as appropriate. I haven't gotten around to that.

I don't like bridge-stp scheme too much either, especially after
realizing the RTNL lock limitation, but it is just enough to get
things working if we don't try to start rstpd from within it (though
the sample does that.) Given the amount of trouble bridge-stp seems to
cause, I should probably work on a different kernel interface for
indicating userspace stp.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Tue, 2008-04-01 at 01:39 +0530, Srinivas M.A. wrote:
> >
> >  I don't like the bridge-stp <bridge> start/stop interface. Why
> >  would bridge-stp know what bridge to run RTSP on? A more natural
> >  way, IMHO, would to extend brctl with a "rstp on" method. Why
> >  is there one rstpctl tool and one brctl tool?
> 
> I wrote rstpctl to just control the rstp daemon. Should integrate it
> with brctl, making it so that brctl checks whether kernel STP or RSTP
> is being used and sets either kernel STP config or sends the config to
> rstpd as appropriate. I haven't gotten around to that.
> 
> I don't like bridge-stp scheme too much either, especially after
> realizing the RTNL lock limitation, but it is just enough to get
> things working if we don't try to start rstpd from within it (though
> the sample does that.) Given the amount of trouble bridge-stp seems to
> cause, I should probably work on a different kernel interface for
> indicating userspace stp.
> 

Curious, why is RSTP in user space? Lots of protocols are in the kernel,
why not RSTP too?

Are any known issues with the in kernel STP?

I haven't read 802.1D-2004 but I know RSTP is in there, does RSTP
replace the old STP protocol? If not, is there any reason to prefer STP
before RSTP in some cases?

 Jocke 

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>
>  Curious, why is RSTP in user space? Lots of protocols are in the kernel,
>  why not RSTP too?

For one thing it is easier from a development standpoint. The kernel
just needs to provide hooks for allowing userspace programs to send
and receive BPDUs and to change port states. The STP logic can then be
moved to userspace and it is easier to develop and debug.

>
>  Are any known issues with the in kernel STP?
>
>  I haven't read 802.1D-2004 but I know RSTP is in there, does RSTP
>  replace the old STP protocol? If not, is there any reason to prefer STP
>  before RSTP in some cases?

In 802.1D-2004, RSTP replaces the old STP. RSTP provides additional
mechanisms to give faster convergence when the network involves only
point-to-point links. It is backward compatible with STP, i.e., it
will interoperate correctly when there are other STP bridges, though
you lose the fast convergence then. So, in general, there is no reason
to prefer STP to RSTP. Currently, the main reason would be that the
STP implementation has been around much longer and that this RSTP
implementation is new.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Tue, 2008-04-01 at 15:27 +0530, Srinivas M.A. wrote:
> >
> >  Curious, why is RSTP in user space? Lots of protocols are in the kernel,
> >  why not RSTP too?
> 
> For one thing it is easier from a development standpoint. The kernel
> just needs to provide hooks for allowing userspace programs to send
> and receive BPDUs and to change port states. The STP logic can then be
> moved to userspace and it is easier to develop and debug.

Yes, but this cannot the only reason to move xSTP to user space? I bet
that is true for lots of stuff currently in kernel, i.e one could move
ARP to user space too. You can probably get better performance with
an in kernel xSTP and possible more robust as you don't depend on a
external process that could get killed by OOM or by user mistake.

> 
> >
> >  Are any known issues with the in kernel STP?
> >
> >  I haven't read 802.1D-2004 but I know RSTP is in there, does RSTP
> >  replace the old STP protocol? If not, is there any reason to prefer STP
> >  before RSTP in some cases?
> 
> In 802.1D-2004, RSTP replaces the old STP. RSTP provides additional
> mechanisms to give faster convergence when the network involves only
> point-to-point links. It is backward compatible with STP, i.e., it
> will interoperate correctly when there are other STP bridges, though
> you lose the fast convergence then. So, in general, there is no reason
> to prefer STP to RSTP. Currently, the main reason would be that the
> STP implementation has been around much longer and that this RSTP
> implementation is new.

Thanks you for the info, much appreciated. I guess the reason why
in kernel STP hasn't been converted to RSTP is the user space approach? 

Sorry for all the questions/criticism, this is all fairly new to me and
I wanted share my initial feelings about RSTP and how it works. Once I
get used to how it all works I generally stop asking myself why/how
things work and just get on with it.

 Jocke

PS.
    I really think you need publish the RSTP work somewhere on the bride
    home page, I had a hard time finding this and I am sure others too
    have problems finding it. 

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Stephen Hemminger]

Joakim Tjernlund wrote:
> On Tue, 2008-04-01 at 15:27 +0530, Srinivas M.A. wrote:
>   
>>>  Curious, why is RSTP in user space? Lots of protocols are in the kernel,
>>>  why not RSTP too?
>>>       
>> For one thing it is easier from a development standpoint. The kernel
>> just needs to provide hooks for allowing userspace programs to send
>> and receive BPDUs and to change port states. The STP logic can then be
>> moved to userspace and it is easier to develop and debug.
>>     
>
> Yes, but this cannot the only reason to move xSTP to user space? I bet
> that is true for lots of stuff currently in kernel, i.e one could move
> ARP to user space too. You can probably get better performance with
> an in kernel xSTP and possible more robust as you don't depend on a
> external process that could get killed by OOM or by user mistake.
>
>   
>>>  Are any known issues with the in kernel STP?
>>>
>>>  I haven't read 802.1D-2004 but I know RSTP is in there, does RSTP
>>>  replace the old STP protocol? If not, is there any reason to prefer STP
>>>  before RSTP in some cases?
>>>       
>> In 802.1D-2004, RSTP replaces the old STP. RSTP provides additional
>> mechanisms to give faster convergence when the network involves only
>> point-to-point links. It is backward compatible with STP, i.e., it
>> will interoperate correctly when there are other STP bridges, though
>> you lose the fast convergence then. So, in general, there is no reason
>> to prefer STP to RSTP. Currently, the main reason would be that the
>> STP implementation has been around much longer and that this RSTP
>> implementation is new.
>>     
>
> Thanks you for the info, much appreciated. I guess the reason why
> in kernel STP hasn't been converted to RSTP is the user space approach? 
>
> Sorry for all the questions/criticism, this is all fairly new to me and
> I wanted share my initial feelings about RSTP and how it works. Once I
> get used to how it all works I generally stop asking myself why/how
> things work and just get on with it.
>
>  Jocke
>
> PS.
>     I really think you need publish the RSTP work somewhere on the bride
>     home page, I had a hard time finding this and I am sure others too
>     have problems finding it. 
>   

There are several motivations for moving it to user space:
  1. As a userspace application it is less vulnerable to being used for 
remote exploits.  Buffer overflows etc
      in kernel are more damaging.
  2. Rstplib is pre-existing code, and can be incorporated easier into 
user application
  3. The real reason is that there are many flavors of STP and and 
configuration and research are more
      easily managed in userspace.

Note: performance is not an issue for STP.

But:
   1. Robustness is harder in userspace
   2. Close coupling of kernel and daemons is maintance pain
   3. Backwards compatibility problems.

Maybe RSTP in userspace is a bad idea, it is possible to go back.
 

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

On Mon, 2008-03-31 at 12:55 +0530, Srinivas M.A. wrote:
> >
> >  Ahh, I didn't copy bridge-stp to /sbin because I didn't think it was
> >  needed. Just to test I blindly copied it to /sbin and did:
> >   brclt addbr br0
> >
> >  brctl addif br0 eth0
> >   brctl stp br0
> >  and it hung my board :(
> 
> What did your /sbin/bridge-stp have. The file from the tarball? Try a
> simple one which just does exit 0.
> 
> >  Meanwhile I got 2 patches for you:
> >
> 
> I didn't realize offsetof() was in stddef.h. Thanks.
> 
> The __builtin_choose_expr stuff is there to trigger a compiler error
> if I try to compare or copy two structs of different sizes. I should
> just make that portion dependent on having a new enough gcc.

Here is a quick hack to make bridge-stp work at all.
The biggest problem is that rstpd cant start if stdio isn't present.
rstpd needs to properly daemonize.

 Jocke

diff --git a/bridge-stp b/bridge-stp
index 49d5a41..0a5ac3c 100755
--- a/bridge-stp
+++ b/bridge-stp
@@ -14,7 +14,7 @@ if [ $# -ne 2 ]; then
 fi
 bridge=$1
 service=rstpd
-pid_file=/var/run/${servicename}.pid
+pid_file=/var/run/${service}.pid
 
 # Set $pid to pids from /var/run* for {program}.  $pid should be declared
 # local in the caller.
@@ -41,7 +41,7 @@ daemon() {
 
     [ -n "$pid" ] && return
     # start it
-    /sbin/rstpd
+    start-stop-daemon  --background --start --exec /sbin/rstpd -- -d
     RETVAL=$?
     [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$service
 }
@@ -53,9 +53,13 @@ start() {
 case $2 in
      start) 
 	daemon
-	exec /sbin/rstpctl $bridge on ;;
+#	exec /sbin/rstpctl $bridge on ;;
+	exit 0 ;;
      stop)  
-	exec /sbin/rstpctl $bridge off ;;
+#	exec /sbin/rstpctl $bridge off ;;
+	start-stop-daemon --stop --exec /sbin/rstpd --name rstpd
+	exit 0 ;;
+
      *)
      	echo "Unknown action:" $2
 	echo "Usage: bridge-stp <bridge> {start|stop}"

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Srinivas M.A.]

>  Here is a quick hack to make bridge-stp work at all.
>  The biggest problem is that rstpd cant start if stdio isn't present.
>  rstpd needs to properly daemonize.

Your change should help (for Debian?), but it maybe best to start
rstpd from the network init scripts, rather than from bridge-stp.
Also, we should not stop the daemon from bridge-stp if there could be
multiple bridges.

Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

> -----Original Message-----
> From: Srinivas M.A. [mailto:srinivas.aji@gmail.com]
> Sent: den 31 mars 2008 19:10
> To: joakim.tjernlund@transmode.se
> Cc: Bridge@lists.linux-foundation.org
> Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary
> problems
> 
> >  Here is a quick hack to make bridge-stp work at all.
> >  The biggest problem is that rstpd cant start if stdio isn't present.
> >  rstpd needs to properly daemonize.
> 
> Your change should help (for Debian?), but it maybe best to start
> rstpd from the network init scripts, rather than from bridge-stp.
> Also, we should not stop the daemon from bridge-stp if there could be
> multiple bridges.

Yes, but I was surprised rstpd just hangs when trying to start it this way.
Could it be the RTNL lock causing this? Maybe rstpd should daemonize earlier
to prevent this from happening?

   Jocke

[Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems

[Joakim Tjernlund]

Hi List

I cloned the above RSTP imp. and cross-compiled it to powerpc and tried
in on my 2.6.23 kernel, but didn't get very far:

Created a bridge, br0, with brctl and added two interfaces.
started rstpd without args and ran rstpctl
  rstpctl showbridge br0
and all I get is
  CTL_get_bridge_state: Got return code 0, 1003
  Failed to get bridge state: Err_Bridge_is_down

The br0 i/f is UP amd RUNNING and so is the interfaces I added.
I probably forgot to do something I suppose, but what?

    Jocke