Hi Claudio,
>Not at the same time,
>controllers don't allow a
>second LE Create
>Connection command if there
>is a pending command.
>My question about your
>controller was how it
>decides in the case that
>it receives connectable
>advertises from more than
>one remote. Does it
>use RSSI(included in the
>advertise) and/or direct
>advertises has
>higher priority?
>
Thanks for the detailed reply. To my understanding, we have no such prioritisation on advertising packets in our controller. I checked with Geert Sonck[copied here], one of our chip experts whom I quote below :-
"There is no such thing as prioritizing. It is first-come first-served. When the connection initiator sees an advertising packet which he should respond to (either because the advertiser is the single destination for the initiation, or because it is in the initiation white-list) it connects to it, irrespective of the RSSI or the packet type (ADV_IND or ADV_DIRECT_IND)". I hope this helps.
>We have been discussing
>internally how to implement
>the connection
>management and new facts
>came up:
>1. If we wanna support GATT
>over BR/EDR, manage
>automatically
>connections in the kernel
>will be hard to keep a
>similar approach for
>LE and basic rate.
>2. Change the server socket
>to "notify" local host
>initiated
>connections is also breaking
>the socket API and requires
>some nasty
>code changes in the kernel.
>3. There are a lot of LE
>kernel patches pending(SM,
>cache and MTU)
>
>After that we decided to
>start our first shot
>managing the connection
>is the usespace(as you
>suggested). Hide the
>resolvable address is
>still possible to be
>implemented in the kernel if
>we manage the
>advertise kernel cache and
>passive scanning properly in
>the kernel.
Yes, I think implementing privacy via use of non-resolvable address should be possible via advertise cache but still we must think about reconnection adresses. Viz how to write a reconnection address to white list for privacy enabled centrals..? I am still trying to catch up on privacy and Guedes cache patches to have clear thoughts on this ...
>
>At the moment the values are
>hardcoded in the kernel.
>Ville sent last
>year a proposal to allow
>changing the connection
>parameters. We didn't
>decide yet we we will use
>management interface or
>extend the socket to
>pass the connection
>parameters.
I think using management interface would be most appropriate if entire bluez would move to it eventually?
Thanks,
Arun
ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±ý¶ â^n‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~††Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø
