All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guy Morand <g.morand@scewo.ch>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Subject: Re: Bluetooth disconnect event / Link layer monitoring
Date: Tue, 19 Nov 2019 10:09:58 +0100	[thread overview]
Message-ID: <CAGssATiZsC28X06aVQDTO=8va-0dtoe-1a2Mi6JZv4P9UMdGqg@mail.gmail.com> (raw)
In-Reply-To: <F827D8AB-4404-4C81-9368-A18AB87D9292@holtmann.org>

Thanks everyone for your quick answers!

I tried this already but unfortunately, it seems that the gamepad
doesn't allow that:
$ hcitool lst ec:83:50:de:02:3c 1
HCI write_link_supervision_timeout request failed: Input/output error

< HCI Command: Write Link Supervision Timeout (0x03|0x0037) plen 4
    handle 70 timeout 1
> HCI Event: Command Complete (0x0e) plen 6
    Write Link Supervision Timeout (0x03|0x0037) ncmd 1
    status 0x0c handle 70
    Error: Command Disallowed

Yes, if it was me, I would never use bluetooth!

I guess the only place where I can do something is in the kernel space.
I would like to send the error to the user when this happens:
Bluetooth: hci0 link tx timeout

Do you think that would be possible and make sense?

Best regards,

Guy

On Tue, Nov 19, 2019 at 6:06 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Luiz,
>
> >> We are developing a wheelchair that we can controle with a bluetooth
> >> gamepad, the XBOX 360 controller to be more precise. It basically works
> >> fine but when I remove the battery, I get the disconnect event in the
> >> user space around 10 seconds later. That is not acceptable since the
> >> wheelchair will keep rolling to potentially dangerous places!
> >>
> >> I tried to implement a ping mechanism on the bluetooth layer, inspired
> >> from bluez sources somewhere:
> >>  int _socket_fd = socket(PF_BLUETOOTH, SOCK_RAW, BTPROTO_L2CAP);
> >>  // bind on AF_BLUETOOTH
> >>  // connect with AF_BLUETOOTH
> >>
> >>  send_cmd->ident = PING_IDENT;
> >>  send_cmd->len = htobs(PING_DATA_SIZE);
> >>  send_cmd->code = L2CAP_ECHO_REQ;
> >>  if (send(_socket_fd, send_buffer, PING_PACKET_SIZE, 0) <= 0) {
> >>    // ...
> >>  }
> >>
> >> It basically works fine except when the signal gets bad. This will get
> >> printed by the kernel:
> >> [  859.629431] Bluetooth: hci0 link tx timeout
> >> [  859.635482] Bluetooth: hci0 killing stalled connection 9c:aa:1b:6b:51:c9
> >>
> >> In that case, I don't get event from the /dev/jsX device but the gamepad
> >> seems to still answer to pings??!!
> >>
> >> Since I haven't found any acceptable workaround and always find the same
> >> pages again and again, I'm asking here:
> >> * Is it possible to achieve what I want?
> >> * Does it make sense that the ping work but the HID layer seems dead?
> >> * Any recommendation, pointers?
> >
> > Id look into adjusting the link supervision timeout instead of
> > creating a raw socket, you can use hcitool to do that, neither is
> > really great since it require root but at least the supervision
> > timeout is something a lot more reliable for this.
>
> we can add an option to L2CAP sockets to adjust the link supervision timeout.
>
> Anyway, these days, I would _not_ use Bluetooth BR/EDR for controlling anything. I would find a Gamepad that utilizes Bluetooth LE and focus on that.
>
> Regards
>
> Marcel
>


-- 

Guy Morand

Software Engineer

–

Scewo AG, Technoparkstrasse 2, 8406 Winterthur

Office +41 (0)44 500 86 03


www.scewo.ch

www.facebook.com/scewo

www.instagram.com/scewo_official

  reply	other threads:[~2019-11-19  9:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18 17:16 Bluetooth disconnect event / Link layer monitoring Guy Morand
2019-11-18 18:27 ` Luiz Augusto von Dentz
2019-11-19  5:06   ` Marcel Holtmann
2019-11-19  9:09     ` Guy Morand [this message]
2019-11-21 17:37       ` Guy Morand
2019-12-02 14:17         ` Guy Morand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGssATiZsC28X06aVQDTO=8va-0dtoe-1a2Mi6JZv4P9UMdGqg@mail.gmail.com' \
    --to=g.morand@scewo.ch \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.