Linux에서 nonblocking 모드로 Bluetooth LE L2CAP 연결을 사용하여 (socket(PF_BLUETOOTH, SOCK_SEQPACKET|SOCK_CLOEXEC, BTPROTO_L2CAP)을 사용하여) ATT 패킷을 읽고 쓸 수있는 응용 프로그램을 작성했습니다. 일반적으로 장치가 꺼 지거나 범위를 벗어나면 read()은 errno = ETIMEDOUT을 제공합니다.Linux에서 과도한 블루투스 LE 타임 아웃이 발생합니까?
그러나 Bluetooth LE 장치가 여전히 작동하는 것처럼 보일 때보 다 read()은 errno = ETIMEDOUT을 제공해야합니다. 타임 아웃의 원인은 무엇입니까? 타임 아웃을 구성 할 수 있습니까?
내 Linux 구성은 3.13.0-24-generic입니다. 블루투스 코어 버전 2.17.
확립 된 LE L2CAP 소켓의 ETIMEDOUT 오류는 실제로 여러 개의 연속 된 누락 패킷 이후에 Bluetooth 어댑터에서 발생합니다. 몇 개가 연결 매개 변수에 따라 다릅니다. 마스터가 슬레이브와 연결을 시작하면 마스터는 연결 간격 (7.5ms-4s)마다 슬레이브를 핑하며 슬레이브는 핑 (ping)을들은 경우 응답합니다. 어떤 장치가 감독 제한 시간 (100ms-32s) 후에 다른 장치로부터 음성을 듣지 못하면 연결을 종료합니다. 세 번째 매개 변수 인 슬레이브 대기 시간 (0-499)을 사용하면 슬레이브는 일부 핑에 응답하지 않아 배터리 전원을 절약 할 수 있습니다. 또한 What are connection parameters?
OS는 연결을 시작할 때 기본 연결 매개 변수를 설정합니다. 슬레이브는 배터리 수명, 대기 시간 및 장애물/간섭에 대한 복원력을 균형있게 조정할 수있는보다 적절한 연결 매개 변수 집합을 권장 할 수 있으며 OS는 이러한 매개 변수를 승인 할 수 있습니다 (Apple의 OS가 수용 할 수있는 연결 매개 변수의 범위는 Apple’s Bluetooth Design Guidelines 참조) . 그러나 슬레이브가 새로운 매개 변수 집합을 제안하지 않는다면 OS 간 격차가 다른 운영 체제의 기본값을 따르는 것입니다!
Wireshark의 hcidump btsnoop 파일을 보면 내 특정 장치 (블루투스 펜)가 다른 간격과 시간 초과를 제안하지 않는 것처럼 보입니다. 따라서 안정성은 OS 기본값에 따라 다릅니다.
여기에는 실험적으로 결정된 기본 간격 및 시간 초과 값이 나와 있습니다. OS에 의해 허용
간격 : 내부 블루투스 어댑터 (currently defined in hci_core.c)와
리눅스 3.13 67.5ms
감시 타임 아웃 : 420ms (분리하는 패킷을 누락 6)
연결 블루투스 어댑터 선택 간격 50-70ms
아이폰 OS 7 아이폰 4S : 블루투스 어댑터에 의해 선택 알 수없는
연결 간격 : 30ms의
OS에 의해 허용
간격슬레이브 대기 시간 : OS에서 허용 넥서스 4
인터벌
안드로이드 5.0.1 막대 사탕 (분리하는 패킷을 누락 23) 720ms : 0 패킷
감독 시간 제한은 블루투스에 의해 선택된
연결 구간을 30-50ms 어댑터 : 48.75ms
슬레이브 대기 : 0 패킷
감시 타임 아웃 : 2000ms
OSX 10.10.1 (애플 블루투스 소프트웨어 버전 : 4.3.1f2 15,015) (분리하는 패킷 누락 41)의 외부 어댑터 :
간격 허용 OS가 불명
는 연결 간격 블루투스 어댑터 선택 : 15ms의
슬레이브 대기 : 0 패킷
감시 타임 아웃 : 2000ms (분리하는 패킷을 누락 133)
이렇게하면 Livescribe 펜에 대한 내 연결이 Linux에서 신뢰성이 떨어지는 이유가 설명됩니다. 커널 기본값은 누락 된 패킷이 6 개 밖에없는 경우 연결을 끊는 것이며 펜은 더 나은 매개 변수를 추천하지 않습니다.
Linux 3.17 이상에서는/sys/kernel/debug/bluetooth/hci0/supervision_timeout에 기록하면 감시 제한 시간을 조정할 수 있습니다.
테스트 방법 : Linux의 추적은 hcidump (Android의 개발자 옵션)를 사용하여 얻었고 HCI LE Create Connection 명령에 대해 Wireshark에서 분석되었습니다. TI의 패킷 스니퍼 소프트웨어와 함께 TI CC2540을 사용하여 OSX 및 iPhone의 흔적을 얻었습니다.