Re: Problem with StopDiscovery() via dbus-send

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Aug 24, 2018 at 11:19 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi,
>
> On Fri, Aug 24, 2018 at 4:58 AM, Проклов Александр Валерьевич
> <ProklovAV@xxxxxxxxxxxxxxxx> wrote:
>>  Hello All,
>>
>> Thanks for your work. Since version bluez-5.50 start-stop discovery work
>> from command line and scripts:
>> #bluetoothctl scan on
>> #bluetoothctl scan off
>> (see mail-list "Problem with StopDiscovery() via dbus-send")
>>
>> --------------------------------------------
>>
>> My next task is to do pair with device from bash script. I tried several
>> ways:
>> 1. #bluetoothctl pair 11:22:33:44:55:66 does not work because the agent is
>> not created.
>> 2. Make  agent via Dbus:
>> #dbus-send --system --print-reply --type=method_call --dest=org.bluez
>> /org/bluez org.bluez.AgentManager1.RegisterAgent objpath:/org/bluez/agent1
>> string:KeyboardOnly
>> the command works, but I do not see in Dbus /org/bluez/agent1 created.
>> 3. Make agent via bluetoothctl:
>> [bluetooth]#agent on
>> the command works, but I do not see in Dbus agent path!.
>
> Im not sure Im following, you would like to have non-interactive mode
> working for bluetoothctl pair? The point number 2 don't make much
> sense since dbus-send normally disconnected after the reply that means
> the agent would be gone, also regarding 3 if you use a more recent
> version of bluetootctl it registers and agent automatically nowadays.
>
>> May be possible to set a default pin code via /etc/bluetooth/main.conf
>> if it is available, do not make a request for a pin from the command line? I
>> think that then #bluetoothctl pair 11:22:33:44:55:66 will be able to work
>> fine.
>
> That is something I had in mind, lets see if I can come up with something.

Actually it doesn't seems to be possible with the current IO
capabilities even if I set KeyboardOnly the phone end up displaying
the passcode on its end, so it seems there is no combination where the
acceptor would be asked to enter a passkey and the initiator to enter
it. I wonder if that is on purpose though, because right now the only
options in case of headless solution would be to use just works and
switch Adapter.Pairable on demand.

-- 
Luiz Augusto von Dentz




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux