Estou tentando conectar o Raspberry Pi ao meu Galaxy Note para usá-lo para comunicação serial. Eu tive um certo sucesso nisso.
Primeiro eu emparelhei e confiei bluetoothctl. Então eu corro sudo rfcomm watch hci0e abri com cat /dev/rfcomm. Consegui me conectar ao Raspberry Pi usandoterminal bluetooth(apenas este aplicativo, todos os outros falharam) e as strings enviadas da galáxia seriam mostradas na catjanela.
De alguma forma, estraguei tudo mais tarde e agora correr sudo rfcomm watch hci0me dá Can't bind RFCOMM socket: Address already in use. Não posso liberá-lo com sudo rfcomm release hci0ou sudo rfcomm release 0como ele me dá Can't release device: No such device. Da mesma forma cat /dev/rfcomm0também agora me dá No such file or directory.
Eu matei o processo listado com sudo lsof | grep /dev/rfcomm0, isso não teve efeito na minha capacidade de usar o RFCOMM. Recarregar systemctl daemon-reloade reiniciar com service bluetooth restarttambém não teve efeito.
Ainda posso procurar outros dispositivos Bluetooth e posso me conectar ao Raspberry Pi com o terminal Bluetooth, mas parece que o rfcomm desapareceu. Estou ciente de que a reinicialização pode resolver isso, embora eu gostaria de fazer isso programaticamente, se possível, sem ter que recorrer ao ciclo de energia.
Obrigado pela ajuda.
Responder1
Verifique a saída do dmesgcomando no Raspberry Pi.
Eu recebo algo como:
[ 296.768548] ------------[ cut here ]------------
[ 296.768576] WARNING: CPU: 3 PID: 40 at drivers/tty/tty_port.c:257 tty_port_put+0x94/0x98
[ 296.768586] Modules linked in: rfcomm cmac bnep hci_uart btbcm serdev bluetooth ecdh_generic 8021q garp stp llc brcmfmac brcmutil bcm2835_codec(C) bcm2835_v4l2(C) v4l2_mem2mem sha256_generic bcm2835_mmal_vchiq(C) v4l2_common videobuf2_vmalloc videobuf2_dma_contig videobuf2_memops cfg80211 videobuf2_v4l2 videobuf2_common videodev media rfkill vc_sm_cma(C) v3d vc4 gpu_sched drm_kms_helper rpivid_mem raspberrypi_hwmon hwmon drm drm_panel_orientation_quirks snd_soc_core snd_bcm2835(C) snd_compress snd_pcm_dmaengine snd_pcm snd_timer syscopyarea sysfillrect sysimgblt fb_sys_fops snd rpi_backlight rpi_ft5406 uio_pdrv_genirq uio evdev joydev ip_tables x_tables ipv6
[ 296.768773] CPU: 3 PID: 40 Comm: kworker/3:1 Tainted: G C 4.19.97-v7l+ #1294
[ 296.768781] Hardware name: BCM2835
[ 296.768798] Workqueue: events release_one_tty
[ 296.768825] [<c0212e04>] (unwind_backtrace) from [<c020d5e0>] (show_stack+0x20/0x24)
[ 296.768844] [<c020d5e0>] (show_stack) from [<c09b15c8>] (dump_stack+0xe0/0x124)
[ 296.768865] [<c09b15c8>] (dump_stack) from [<c0222544>] (__warn+0x104/0x11c)
[ 296.768883] [<c0222544>] (__warn) from [<c0222694>] (warn_slowpath_null+0x50/0x58)
[ 296.768899] [<c0222694>] (warn_slowpath_null) from [<c06cab28>] (tty_port_put+0x94/0x98)
[ 296.768941] [<c06cab28>] (tty_port_put) from [<bf9dd2a0>] (rfcomm_tty_cleanup+0x5c/0x60 [rfcomm])
[ 296.768999] [<bf9dd2a0>] (rfcomm_tty_cleanup [rfcomm]) from [<c06c2a38>] (release_one_tty+0x3c/0xac)
[ 296.769019] [<c06c2a38>] (release_one_tty) from [<c023e028>] (process_one_work+0x170/0x458)
[ 296.769036] [<c023e028>] (process_one_work) from [<c023e36c>] (worker_thread+0x5c/0x5a4)
[ 296.769051] [<c023e36c>] (worker_thread) from [<c02446a0>] (kthread+0x138/0x168)
[ 296.769066] [<c02446a0>] (kthread) from [<c02010ac>] (ret_from_fork+0x14/0x28)
[ 296.769075] Exception stack(0xefab3fb0 to 0xefab3ff8)
[ 296.769086] 3fa0: 00000000 00000000 00000000 00000000
[ 296.769098] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 296.769108] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 296.769119] ---[ end trace 545b669f95e0d2b5 ]---
O que me faz acreditar que o módulo do kernel (rfcomm) e seu thread de processamento (krfcomm) travaram/travaram ao liberar o tty e o deixaram em um estado quebrado.
Como resultado, as tentativas de criar um novo entram em conflito com aquele que ainda não foi excluído, enquanto as tentativas de excluir/liberar o existente resultam em uma mensagem informando que o dispositivo não existe.
Não acredito que haja uma solução neste momento, além de reiniciar.
Li em algum lugar que se você garantir que a conexão permaneça aberta por mais de 10 segundos, a falha não ocorrerá e a porta poderá ser reutilizada com sucesso.
Editar: A seguinte resposta à mesma pergunta no SO sugere a remoção do modemmanagerpacote, o que pode estar interferindo.