Re: [PATCH 1/1] add configurable support for bridge forward delay

[Thomas Egerer <hakke_007@gmx.de>]

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

Luiz

Luiz Augusto von Dentz wrote:
> Hi.
>
> On Wed, Jan 27, 2010 at 9:19 PM, Thomas Egerer <hakke_007@gmx.de> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> Luiz,
>>
>> Luiz Augusto von Dentz wrote:
>>> Hi Thomas,
>>>
>>> On Tue, Jan 26, 2010 at 7:44 PM, Thomas Egerer
<thomas.washeim@gmx.net> wrote:
>>>> 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
>> :D
>>>
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.
>> 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
>> 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.
>
> You probably didn't read this documentation:
>
>
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge_stp
I indeed read that documentation.

> "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.

> 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.

> 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?

Cheers,

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREKAAYFAkth360ACgkQ2/ggQBUI/snpkwCfSmSurtaE2mQv8QwMjugC4EAi
XYUAoI342Qt4rEyqVNDV3NudSDCgujCP
=hyEd
-----END PGP SIGNATURE-----