RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems
A message that is not in the archive (sent off-list or not yet received): 8571495929364495836@unknownmsgid
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.)
Quoted 37 lines · Joakim Tjernlund
Quoted 18 lines
-----Original Message-----
From: Joakim Tjernlund [mailto:[email protected]]
Sent: den 29 mars 2008 17:22
To: '[email protected]'
Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problemsHi 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_downQuoted 4 lines
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
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/bridge
Hi Srinivas
Quoted 6 lines · Srinivas M.A.
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.
Quoted 2 lines
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?
Quoted 2 lines
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.
Quoted 2 lines
I don't know how the mailing list handles attachments, let me see anyway.
Got both of them.
Quoted 10 lines
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.
Quoted 25 lines
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/rstpctlrstp $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.
Quoted 5 lines
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
Quoted 35 lines
Quoted 31 lines · Joakim Tjernlund
Quoted 18 lines
-----Original Message-----
From: Joakim Tjernlund [mailto:[email protected]]
Sent: den 29 mars 2008 17:22
To: '[email protected]'
Subject: RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary problemsHi 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_downQuoted 4 lines
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
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
:) 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
Quoted 9 lines · Srinivas M.A.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
:) 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
Quoted 28 lines · Joakim Tjernlund
Quoted 9 lines · Srinivas M.A.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
:) 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"
Quoted 2 lines
Seems like
__builtin_offsetofisn'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
Quoted 53 lines · Joakim Tjernlund
Quoted 28 lines · Joakim Tjernlund
Quoted 9 lines · Srinivas M.A.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 1 line
Quoted 7 lines
Quoted 2 lines
:) 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"Quoted 2 lines
Seems like
__builtin_offsetofisn'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 showbridgebr0
enabled no
bridge id 8000.002234567778
designated root 0000.000000000000root 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
Quoted 7 lines
time since topology change 354
toplogy change count 0
topology change noIt 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
Quoted 8 lines
-----Original Message-----
From: Srinivas M.A. [mailto:[email protected]]
Sent: den 30 mars 2008 11:32
To: Joakim Tjernlund
Cc: [email protected]
Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems
Quoted 5 lines
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.
Quoted 6 lines
Thanks.
Srinivas.
P.S.: One note on bridge-stp and general bridge startup.
Quoted 7 lines
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/rstpctlrstp $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)?
Quoted 11 lines
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?
Quoted 6 lines
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.)
A message that is not in the archive (sent off-list or not yet received): 7423344835968003573@unknownmsgid
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
hmm, how does
stp_statebecome 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")
Quoted 9 lines
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
Quoted 3 lines
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.
Quoted 1 line
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.
Quoted 45 lines · Srinivas M.A.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
hmm, how does
stp_statebecome 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 setsstp_stateto 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_stateis 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")Quoted 8 lines
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
Quoted 8 lines
Quoted 3 lines
It does not get enabled and
#> cat/sys/class/net/br0/bridge/stp_state
1This should have worked. Could you check that
/sbin/bridge-stphas 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 <[email protected]>
Date: Sun, 30 Mar 2008 22:45:40 +0200
Subject: [PATCH] offsetof is defined in stddef.h, use that.
--- rstp.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
rstp.c +4 -3
@@ -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)
Signature · 12 lines
1.5.4.3 From 14fc4be633e28e4ec7c1be7635e52f5ca44abc1b Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund <[email protected]> Date: Sun, 30 Mar 2008 22:59:07 +0200 Subject: [PATCH] Replace gcc extension with C. Signed-off-by: Joakim Tjernlund <[email protected]> --- rstp.c | 19 +++++++------------ 1 files changed, 7 insertions(+), 12 deletions(-)
rstp.c +7 -12
@@ -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
Signature · 5 lines
1.5.4.3 These are not tested as I manged to hang my board, stupid me beeing to impatient. Jocke
Quoted 26 lines
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 theLOG_DEBUGmessages as well to see them, or just fix the code to get all the messages atLOG_INFO.Quoted 1 line
Have this code been tested on a big endian CPU?
No, only ix86 and
x86_64at 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_stateas 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.
Quoted 8 lines
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 br0brctl 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.
Quoted 2 lines
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.
Quoted 11 lines · Srinivas M.A.
Quoted 8 lines
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 br0brctl addif br0 eth0
brctl stp br0
and it hung my board :(What did your
/sbin/bridge-stphave. 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() = 245bind(3, {sa_family=AF_FILE, path=@RSTPCTL_245}, 110) = 0 connect(3, {sa_family=AF_FILE, [email protected]_server}, 110) = -1 ECONNREFUSED (Connection refused)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Process 245 detached
[email protected]:~# 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
Quoted 5 lines
Quoted 3 lines
Meanwhile I got 2 patches for you:
I didn't realize
offsetof()was instddef.h. Thanks.
I you want, you can remove the #ifndef too, gcc 3.4.6 has offsetof in stddef.h
Quoted 4 lines
The
__builtin_choose_exprstuff 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
Quoted 3 lines
So I both get a SEGV and the kernel thinks userspace is running STP, not ideal.
Segfault is fixed by this:
log.h +1 -1
@@ -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...) \
Quoted 3 lines
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.
Quoted 19 lines
-----Original Message-----
From: Srinivas M.A. [mailto:[email protected]]
Sent: den 31 mars 2008 19:00
To: [email protected]
Cc: [email protected]
Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problemsQuoted 3 lines
So I both get a SEGV and the kernel thinks userspace is running STP, not ideal.
Segfault is fixed by this:
log.h +0
-0
log.h extern int log_level; · line 69
Quoted 8 lines
log.h +1
-1@@ -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
Quoted 12 lines
Quoted 5 lines
I really think one should be able to start RSTP with rtspctl too so one doesn't need
/sbin/bridge-stpbridge-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.
Quoted 7 lines
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?
Quoted 6 lines
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
A message that is not in the archive (sent off-list or not yet received): -2617425004832712825@unknownmsgid
Quoted 5 lines
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.
Quoted 11 lines · Srinivas M.A.
Quoted 5 lines
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.
Quoted 7 lines
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
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines · Srinivas M.A.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 7 lines
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?
Quoted 8 lines
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.
Quoted 42 lines · Joakim Tjernlund
Quoted 8 lines · Srinivas M.A.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 6 lines
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?
Quoted 9 lines
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.
Quoted 7 lines
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.
Quoted 12 lines · Srinivas M.A.
Quoted 8 lines
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 br0brctl addif br0 eth0
brctl stp br0
and it hung my board :(What did your
/sbin/bridge-stphave. The file from the tarball? Try a simple one which just does exit 0.
Quoted 8 lines
Quoted 2 lines
Meanwhile I got 2 patches for you:
I didn't realize
offsetof()was instddef.h. Thanks.The
__builtin_choose_exprstuff 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
bridge-stp +8 -4
@@ -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}"
Quoted 3 lines
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.
Quoted 8 lines
-----Original Message-----
From: Srinivas M.A. [mailto:[email protected]]
Sent: den 31 mars 2008 19:10
To: [email protected]
Cc: [email protected]
Subject: Re: [Bridge] RSTP in http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git; a=summary problems
Quoted 8 lines
Quoted 3 lines
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