search

martinohanlon / BlueDot

A zero boiler plate bluetooth remote
MIT License
143 stars 44 forks source link

OSError: [Errno 38] Function not implemented #135

Closed LeeHounshell closed 4 years ago

LeeHounshell commented 4 years ago

Fill in the details or delete as appropriate :)

Describe the bug I am using a Jetson Nano with the BlueDot Bluetooth server, connected to an Android app. When the server crashes during a session (say due to a ctrl-C interrupt), the next time it is run it will crash again after a few minutes, always with OSError 38.

If the Bluetooth connection terminates naturally, then this problem does not happen. In that case I can crash and restart the server, no problem. Only if I crash it during an active connection, OSError 38 happens.

Included below is a stack trace.

Exception in thread Thread-1: Traceback (most recent call last): File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner self.run() File "/usr/lib/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/usr/local/lib/python3.6/dist-packages/bluedot/btcomm.py", line 440, in _wait_for_connection self._read() File "/usr/local/lib/python3.6/dist-packages/bluedot/btcomm.py", line 454, in _read self._handle_bt_error(e) File "/usr/local/lib/python3.6/dist-packages/bluedot/btcomm.py", line 486, in _handle_bt_error raise bt_error File "/usr/local/lib/python3.6/dist-packages/bluedot/btcomm.py", line 452, in _read data = self._client_sock.recv(1024, socket.MSG_DONTWAIT) OSError: [Errno 38] Function not implemented

To Reproduce Steps to reproduce the behavior:

  1. start BlueDot Bluetooth python server on Jetson Nano
  2. connect to the server using an Android app
  3. start communications
  4. crash the python server
  5. restart the python server
  6. reconnect the Android app
  7. start communications again
  8. wait for the error to happen

Expected behavior no OSError 38 - or some way to trap the error and recover when it happens.

Screenshots N/A

System (please complete the following information):

Additional context $ systemctl status bluetooth ● bluetooth.service - Bluetooth service Loaded: loaded (/etc/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/bluetooth.service.d └─nv-bluetooth-service.conf Active: active (running) since Fri 2019-09-20 12:19:28 PDT; 3 days ago Docs: man:bluetoothd(8) Main PID: 5752 (bluetoothd) Status: "Running" Tasks: 1 (limit: 4182) CGroup: /system.slice/bluetooth.service └─5752 /usr/lib/bluetooth/bluetoothd -C -d --noplugin=audio,a2dp,avrcp

Sep 24 09:41:25 batbot bluetoothd[5752]: src/adapter.c:adapter_remove_connection() Sep 24 09:41:25 batbot bluetoothd[5752]: plugins/policy.c:disconnect_cb() reason 0 Sep 24 09:41:25 batbot bluetoothd[5752]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 08:AE:D6:81:04:9A type 0 status 0xe Sep 24 09:41:25 batbot bluetoothd[5752]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e Sep 24 09:41:25 batbot bluetoothd[5752]: src/device.c:device_bonding_failed() status 14 Sep 24 09:41:25 batbot bluetoothd[5752]: src/adapter.c:resume_discovery() Sep 24 10:02:45 batbot bluetoothd[5752]: src/profile.c:ext_exited() "Serial Port" exited Sep 24 10:02:45 batbot bluetoothd[5752]: src/profile.c:ext_adapter_remove() "Serial Port" removed Sep 24 10:02:45 batbot bluetoothd[5752]: src/profile.c:ext_adapter_remove() "Serial Port" removed Sep 24 10:02:45 batbot bluetoothd[5752]: src/profile.c:remove_ext() Removed "Serial Port"

$ pip freeze | grep -i bluedot bluedot==1.3.2

$ dpkg --status bluez Package: bluez Status: install ok installed Priority: optional Section: admin Installed-Size: 4181 Maintainer: Ubuntu Bluetooth team ubuntu-bluetooth@lists.ubuntu.com Architecture: arm64 Multi-Arch: foreign Version: 5.48-0ubuntu3.1 Replaces: bluez-alsa, bluez-audio (<= 3.36-3), bluez-input, bluez-network, bluez-serial, bluez-utils (<= 3.36-3), udev (<< 170-1) Depends: libc6 (>= 2.17), libdbus-1-3 (>= 1.9.14), libglib2.0-0 (>= 2.31.8), libreadline7 (>= 6.0), libudev1 (>= 196), kmod, udev (>= 170-1), lsb-base, dbus Breaks: udev (<< 170-1) Conflicts: bluez-alsa, bluez-audio (<= 3.36-3), bluez-utils (<= 3.36-3) Conffiles: /etc/bluetooth/input.conf 9f85017f861ac34d983fa76fa715f9c3 /etc/bluetooth/main.conf 445fdaa9def1ffaa873df2447ba22004 /etc/bluetooth/network.conf 0c7497c405b963382ff71789d0730abd /etc/dbus-1/system.d/bluetooth.conf 92d4ee9390a14cdf225b79d8009b6f79 /etc/init.d/bluetooth 33ed7811d65a775cf10f04c2e6ee3cbf Description: Bluetooth tools and daemons This package contains tools and system daemons for using Bluetooth devices. . BlueZ is the official Linux Bluetooth protocol stack. It is an Open Source project distributed under GNU General Public License (GPL). Homepage: http://www.bluez.org Original-Maintainer: Debian Bluetooth Maintainers pkg-bluetooth-maintainers@lists.alioth.debian.org

----outline of the code i am using on the server side---- ` 

#!/usr/bin/python3

from bluedot.btcomm import BluetoothServer
from datetime import datetime
from signal import pause

import serial
import socket
import struct
import subprocess
import time

port = '/dev/ttyACM0' # note I'm using Jetson Nano
arduino = serial.Serial(port,9600,timeout=5)
time.sleep(2) # wait for Arduino

def data_received(commandsFromPhone):
    commandList = commandsFromPhone.splitlines()
    for data in commandList:
        # do some stuff with data, including write and read to/from the arduino
        result = read_data_from_arduino()
        s.send(data + '\n' + result)

try:
    s = BluetoothServer(data_received)
    print('---> waiting for connection <---')
    pause()
except Exception as e:
    print("PROGRAM ERROR: e=" + str(e))

`

martinohanlon commented 4 years ago

Im not sure what to suggest here...

There is nothing special happening here - the BluetoothServer is making a recv socket method call and the OS is reporting something is wrong! (there could be a multitude of things which could causing an issue)

Its not something I have seen on other hardware platforms / operating systems and I have no way of re-creating the issue.

Things which come to mind. Could the client be maintaining a connection? Is there a race condition in your program which is causing the socket to be kept alive / open? Is there a thread still running somewhere which is blocking something?

I cant (realistically) refactor the BluetoothServer so the error could be captured, it doesnt work that way and it would negatively affect BlueDot, the only reason for its existence.

If I was facing this problem I would create my own server which I could have low level control of and debug that way (this is ultimately what I had to do when creating BlueDot). BluetoothServer might be good place to start.

Im going to close as "not going to fix", but happy to offer any advice if I can.

LeeHounshell commented 4 years ago

Thanks Martin,

I do appreciate your input. I also believe this is somehow tied to the Android app I am using. It also becomes "confused" when the server is interrupted. I am thinking there is something I am missing on the Android side. I will look at any open socket connection and debug as you suggest.

As an aside, I really like your BlueDot. I am using it for the robot project I am working on.

On Wed, Sep 25, 2019 at 12:33 PM martinohanlon notifications@github.com wrote:

Im not sure what to suggest here...

There is nothing special happening here - the BluetoothServer is making a recv socket method call and the OS is reporting something is wrong! (there could be a multitude of things which could causing an issue)

Its not something I have seen on other hardware platforms / operating systems and I have no way of re-creating the issue.

Things which come to mind. Could the client be maintaining a connection? Is there a race condition in your program which is causing the socket to be kept alive / open? Is there a thread still running somewhere which is blocking something?

I cant (realistically) refactor the BluetoothServer so the error could be captured, it doesnt work that way and it would negatively affect BlueDot, the only reason for its existence.

If I was facing this problem I would create my own server which I could have low level control of and debug that way (this is ultimately what I had to do when creating BlueDot). BluetoothServer might be good place to start.

Im going to close as "not going to fix", but happy to offer any advice if I can.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martinohanlon/BlueDot/issues/135?email_source=notifications&email_token=AAH33FOHRHADUZPPBSREJK3QLO4JLA5CNFSM4I2CM35KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7TCQJA#issuecomment-535177252, or mute the thread https://github.com/notifications/unsubscribe-auth/AAH33FNMOBWPG4QUKQ7GYV3QLO4JLANCNFSM4I2CM35A .

LeeHounshell commented 4 years ago

I found the problem here. The root cause was Android Kotlin Fragments not properly destroying themselves and leaving partial connections in the connected ViewModel's Bluetooth Server thread.

martinohanlon commented 4 years ago

Well done.