add configurable support for bridge forward delay

the default learning time of a bridge -- 15 seconds -- appears unacceptably long, especially for clients that disconnect quite often after a short time (e.g. web-browsers);
this patch tries to remedy this by setting the the waiting period to a value of zero (by default) or -- if the administrator wishes a larger value -- to whatever the General section of the network.conf holds in the variable ForwardDelay;

---
 Makefile.am       |    2 +-
 acinclude.m4      |    6 +++
 configure.ac      |    1 +
 network/bridge.c  |  117
++++++++++++++++++++++++++++++++++++++++++++++++++++-
 network/bridge.h  |    3 +-
 network/manager.c |   19 +++++++-
 6 files changed, 142 insertions(+), 6 deletions(-)

Hi Thomas,
[...]
using libsysfs is not acceptable. That library is deprecated.

I get your point, but what's your suggestion? The ioctl is marked deprecated, too and the problem of setting the forward delay persists. Would it suffer your needs if I got rid of libsysfs in general and simply use the ioctl or is there a different replacement strategy you prefer?

Hi Thomas,

Quoted 5 lines

I get your point, but what's your suggestion? The ioctl is marked deprecated, too and the problem of setting the forward delay persists. Would it suffer your needs if I got rid of libsysfs in general and simply use the ioctl or is there a different replacement strategy you prefer?

if it has an ioctl, then use that one. I really don't understand why everybody things ioctl are bad. They work just fine and are often simpler to handle than sysfs files.

Hi,

Quoted 10 lines · Marcel Holtmann

Hi Thomas,

Quoted 5 lines

I get your point, but what's your suggestion? The ioctl is marked deprecated, too and the problem of setting the forward delay persists. Would it suffer your needs if I got rid of libsysfs in general and simply use the ioctl or is there a different replacement strategy you prefer?

if it has an ioctl, then use that one. I really don't understand why everybody things ioctl are bad. They work just fine and are often simpler to handle than sysfs files.

The documentation on
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
state:

"If the bridge is being used standalone (no other bridges near by). Then it is safe to turn the forwarding delay off (set it to zero), before adding interface to a bridge. Then you can run DHCP client right away." Which I guess is what the PAN spec expects for a NAP server, so perhaps having another entry in network.conf is not really needed or only really useful for a GN server if someone is messing with it e.g. mesh network, but even for that purpose it just seems wrong to expect that in a fixed amount of time it will be able to resolve the topology, so why bother?

Luiz,
let me tell you why I'd like to have an extra config variable. Let's imagine an admin who want to add the upcoming bnep interfaces to an _already_ existing bridge (for that matter a test whether the given interface name already exists would be nice, too) plus he knows about the infrastructure behind the bridge and decides to set a different forward delay. He could, of course reset the delay, once the bridge is up. But ideally he would specify the setting in the network.conf. Hence the extra config variable (which btw. were actually two variables by the time I started writing the patch).

Hi Thomas,

Quoted 10 lines · Thomas Egerer

Luiz,
let me tell you why I'd like to have an extra config variable. Let's imagine an admin who want to add the upcoming bnep interfaces to an _already_ existing bridge (for that matter a test whether the given interface name already exists would be nice, too) plus he knows about the infrastructure behind the bridge and decides to set a different forward delay. He could, of course reset the delay, once the bridge is up. But ideally he would specify the setting in the network.conf. Hence the extra config variable (which btw. were actually two variables by the time I started writing the patch).

In lets say a pure network sense you are probably right, but what Im arging about is that the PAN spec doesn't mentioned anything about this, so in the spec sense once you accept the connection the interface _is_ already fully functional. So either we always set the delay to 0 or we have to wait until the interface is ready to accept the connection, although the second alternative is doable it happens to be after the connection is accepted that the network interface is created and there is no way to inform the other part that there is an arbitrary delay before the interface become functional again.

Luiz,

I disagree. On page 31 the specification states that a NAP/GN performs the following (in regard to packet forwarding operations):
'Automatically learn and maintain the information required to make frame-filtering decisions as described in [3] section 7.1 and specified in [3] sections 7.8 and 7.9, for the support of Basic Filtering Services.=

and even if it says in the next paragraph:
'The NAP/GN is not required to perform any of the following aspects of the 802.1D standard.'
footnote 4 mentions:
'Sophisticated Bluetooth NAP devices may choose to implement some or all of the 802.1D features.'
In my eyes this supports my point of view since the forward delay as part of the learning process should be a subject of configuration. Could I convince you?

Hi Thomas,

Quoted 16 lines · Thomas Egerer

Luiz,

I disagree. On page 31 the specification states that a NAP/GN performs the following (in regard to packet forwarding operations):
'Automatically learn and maintain the information required to make frame-filtering decisions as described in [3] section 7.1 and specified in [3] sections 7.8 and 7.9, for the support of Basic Filtering Services.' and even if it says in the next paragraph:
'The NAP/GN is not required to perform any of the following aspects of the 802.1D standard.'
footnote 4 mentions:
'Sophisticated Bluetooth NAP devices may choose to implement some or all of the 802.1D features.'
In my eyes this supports my point of view since the forward delay as part of the learning process should be a subject of configuration. Could I convince you?

You almost convince me, but after some googling it seems

http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Spanning_Tree_Protocol
contradicts what you are saying:

"The Spanning Tree Protocol has no authentication; all participants are assumed to be trustworthy and correct. This assumption is not true if bridging between a hostile environment like the Internet and a private network. For this reason, STP is turned off by default on the recent versions of Linux."

And even the spec itself seem to support my argument:

"2004 — Revised version (802.1D-2004), incorporating the extensions 802.11c, 802.1t and 802.1w, which were separately published in 2001, and removing the original Spanning tree protocol, instead incorporating the Rapid Spanning Tree Protocol (RSTP) from 802.1w."

Naturally someone else also notice that this arbitrary delay during the learning phase is a bad idea after all and invented the RSTP and I guess PAN spec was released after 2004 so that would explain why we don't see anything about how to handle forwarding delay.

Hi.

Quoted 9 lines · Thomas Egerer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Luiz,

Quoted 3 lines · Luiz Augusto von Dentz

Hi Thomas,

On Tue, Jan 26, 2010 at 7:44 PM, Thomas Egerer

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Luiz,

I disagree. On page 31 the specification states that a NAP/GN performs the following (in regard to packet forwarding operations):
'Automatically learn and maintain the information required to make frame-filtering decisions as described in [3] section 7.1 and specified in [3] sections 7.8 and 7.9, for the support of Basic Filtering

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

and even if it says in the next paragraph:
'The NAP/GN is not required to perform any of the following aspects of the 802.1D standard.'
footnote 4 mentions:
'Sophisticated Bluetooth NAP devices may choose to implement some

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

of the 802.1D features.'
In my eyes this supports my point of view since the forward delay as part of the learning process should be a subject of configuration. Could I convince you?

You almost convince me, but after some googling it seems

:D

Quoted 1 line

Quoted 19 lines

Quoted 19 lines

contradicts what you are saying:

"The Spanning Tree Protocol has no authentication; all participants are assumed to be trustworthy and correct. This assumption is not true if bridging between a hostile environment like the Internet and a private network. For this reason, STP is turned off by default on the recent versions of Linux."

And even the spec itself seem to support my argument:

"2004 — Revised version (802.1D-2004), incorporating the extensions 802.11c, 802.1t and 802.1w, which were separately published in 2001, and removing the original Spanning tree protocol, instead incorporating the Rapid Spanning Tree Protocol (RSTP) from 802.1w."

Naturally someone else also notice that this arbitrary delay during the learning phase is a bad idea after all and invented the RSTP and I guess PAN spec was released after 2004 so that would explain why we don't see anything about how to handle forwarding delay.

Quoted 5 lines

That's at least an explanation why one cannot find how to configure the forward delay for the bridge.
This is where the use case comes into play. You allow the user to configure the bridge to use (which by the way is only created for GN and not for NAP, is that correct?). If you do so one might (for various

Quoted 8 lines

reasons) want to choose an existing bridge (which results in a simple error message without giving the actual reason). But if the user picks a bridge that already exists and you use a fix, not configurable delay one has to reset the delay -- if necessary -- to something -ne 0 after bluetoothd was started.
If one doesn't specify the value it's set to the default, zero seconds, no harm done, if one does specify the value this one is used. I can't see where the problem is.

You probably didn't read this documentation:

"STP is turned off by default on the recent versions of Linux"

afaik it will be pretty hard to convince Marcel about adding something that is not enabled by default anymore

And again STP is _obsolete_ according to 802.1D-2004 (we are in 2010), I don't know why you are spending time trying to use STP in the first place, If I were you I would spend my time implementing RSTP or MSTP that would be great not only for bluetooth but also for networking in general.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Luiz

Quoted 12 lines · Luiz Augusto von Dentz

Hi.

Quoted 9 lines · Thomas Egerer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Luiz,

Quoted 3 lines · Luiz Augusto von Dentz

Hi Thomas,

On Tue, Jan 26, 2010 at 7:44 PM, Thomas Egerer

Quoted 7 lines · <[email protected]> wrote:

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

Luiz,

I disagree. On page 31 the specification states that a NAP/GN performs the following (in regard to packet forwarding operations):
'Automatically learn and maintain the information required to make frame-filtering decisions as described in [3] section 7.1 and specified in [3] sections 7.8 and 7.9, for the support of Basic Filtering

Services.'

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

and even if it says in the next paragraph:
'The NAP/GN is not required to perform any of the following aspects of the 802.1D standard.'
footnote 4 mentions:
'Sophisticated Bluetooth NAP devices may choose to implement some

or all

Quoted 7 lines

Quoted 7 lines

Quoted 5 lines

Quoted 4 lines

of the 802.1D features.'
In my eyes this supports my point of view since the forward delay as part of the learning process should be a subject of configuration. Could I convince you?

You almost convince me, but after some googling it seems

:D

Quoted 1 line

http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Spanning_Tree_Protocol

Quoted 19 lines

Quoted 19 lines

Quoted 19 lines

contradicts what you are saying:

"The Spanning Tree Protocol has no authentication; all participants are assumed to be trustworthy and correct. This assumption is not true if bridging between a hostile environment like the Internet and a private network. For this reason, STP is turned off by default on the recent versions of Linux."

And even the spec itself seem to support my argument:

"2004 — Revised version (802.1D-2004), incorporating the extensions 802.11c, 802.1t and 802.1w, which were separately published in 2001, and removing the original Spanning tree protocol, instead incorporating the Rapid Spanning Tree Protocol (RSTP) from 802.1w."

Naturally someone else also notice that this arbitrary delay during the learning phase is a bad idea after all and invented the RSTP and I guess PAN spec was released after 2004 so that would explain why we don't see anything about how to handle forwarding delay.

Quoted 13 lines

Quoted 5 lines

That's at least an explanation why one cannot find how to configure the forward delay for the bridge.
This is where the use case comes into play. You allow the user to configure the bridge to use (which by the way is only created for GN and not for NAP, is that correct?). If you do so one might (for various

Quoted 8 lines

reasons) want to choose an existing bridge (which results in a simple error message without giving the actual reason). But if the user picks a bridge that already exists and you use a fix, not configurable delay one has to reset the delay -- if necessary -- to something -ne 0 after bluetoothd was started.
If one doesn't specify the value it's set to the default, zero seconds, no harm done, if one does specify the value this one is used. I can't see where the problem is.

First of all, I'm feeling a bit like an idiot here. The only thing I tried to do was improving bluez. And I'd give a rats ass about it if I didn't use it every day. So I have personal interest to make the software as good and usable as possible for me as well as other people.

Quoted 4 lines

You probably didn't read this documentation:

http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge_stp
I indeed read that documentation.

Quoted 1 line

"STP is turned off by default on the recent versions of Linux"

And I sure know that. I'm using bridges quite often and 'brctl show' lists a field called 'STP enabled' which is set to off unless you change it manually.

Quoted 2 lines

afaik it will be pretty hard to convince Marcel about adding something that is not enabled by default anymore

This must be a misunderstanding. I'm don't want to enable STP by default or whatever. My intention is (see me 'foreword' from above) to make the bluetoothd as user-friendly as even possible. And this includes for me to check for an existing bridge (this means honoring the EEXIST return code in bridge_create) first off. Then secondly leaving the bridge's settings untouched or setting it to the user-defined values from network.conf.

Quoted 5 lines

And again STP is _obsolete_ according to 802.1D-2004 (we are in 2010), I don't know why you are spending time trying to use STP in the first place, If I were you I would spend my time implementing RSTP or MSTP that would be great not only for bluetooth but also for networking in general.

Again, I don't want to enable STP by default, I want people to be able to use bluetooth in a fashion they want (which includes honoring that an existing bridge keeps using its existing settings/set user defined values for a newly created bridge).
I know RSTP would be great, but it's not in the kernel. Support would be available via user-space lib, but all the project to find in this direction seem to be dead.
So as a compromise, do you think it would be possible to 'convince' Marcel to leave a bridge's settings untouched as long as it exists and use the (reasonable) default values like a forward delay of zero seconds for newly created bridges?