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

Regards,

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

iEYEAREKAAYFAktgkd0ACgkQ2/ggQBUI/skpKgCeOa18EGr9GviCRf/PUU70p1YM
gKYAnjnAeujBsKiEQRBeqeYIDZ7HRutG
=3VWl
-----END PGP SIGNATURE-----