my TP-Link Archer C7v2|5 WiFi APs are equipped with bluetooth LE USB dongles and perform regular scans for known BT paired devices. I noticed a lot of those log lines after upgrading OpenWrt from 19.07.5 to 21.02.0-rc.1. Now I've upgraded to 21.02.0-rc.2 and still have a lot of those lines in my logread output.
Is this something pointing at a failure or problem? My bluetooth scans still run normally, but the syslog-server collecting all AP's logs receives a lot of "logspam".
Maybe those events in the kernel were just not visible in logread's output on 19.07.x?
Jun 6 19:47:01 WifiAP-02 kernel: [ 1739.445025] debugfs: File 'le_min_key_size' in directory 'hci0' already present!
Jun 6 19:47:01 WifiAP-02 kernel: [ 1739.452742] debugfs: File 'le_max_key_size' in directory 'hci0' already present!
Jun 6 19:47:01 WifiAP-02 kernel: [ 1739.460385] debugfs: File 'force_bredr_smp' in directory 'hci0' already present!
Thank you for your answer.
Update: Those kernel messages only occur when I use this Bluetooth USB low-energy (BLE) dongle. It has a Broadcom BCM20702 chipset and its USB device/manufacturer ID is as follows:
The label on top of the device says: "Model UDC-324E" (can be found at: https://www.amazon.co.uk/Shengwei-UDC-324-Bluetooth-Adapter-Transmission/dp/B01D2JJRFE ).
The device works well, but I wonder what those repeating log lines mean.
Will this be fixed when 21.02.0-rc.3 is out? Still getting a lot of the above log messages filling the syslog server up quickly.
The files the kernel message refers to are found in:
drwxr-xr-x 2 root root 0 Jun 17 17:55 ./
drwxr-xr-x 3 root root 0 Jun 17 17:54 ../
-rw-r--r-- 1 root root 0 Jun 17 17:55 dut_mode
-rw-r--r-- 1 root root 0 Jun 17 17:55 force_bredr_smp
-rw-r--r-- 1 root root 0 Jun 17 17:55 le_max_key_size
-rw-r--r-- 1 root root 0 Jun 17 17:55 le_min_key_size
I cannot "rm -f" those files to allow "debugfs" to recreate them (just a guess). It says "rm not permitted".
Btw: I did a "dmesg | wc -l" as two of four Archer C7's are crashing with less than 2 days uptime. It turned out those two are the units with the BT USB dongles constantly emitting the above kernel debugfs error message. (> 1500 dmesg log lines after 8 hours!!). My other two units don't have bluetooth USB dongles and they are up 10 days with dmesg about 200 lines.
It seems those message are not of a functional problem nature, but if too many of them get logged, the unit crashes (out of memory?).
My scripts just does a:
hciconfig -a hci0 down
hciconfig -a hci0 up
hcitool info [bt-mac-address]
"hcitool -a hci0 up" is the command which leads to the debugfs kernel message.
Just can't get the message away... here's my package versions:
bluez-daemon - 5.56-1
bluez-libs - 5.56-1
bluez-utils - 5.56-1
bluez-utils-extra - 5.56-1
Maybe related out of Google: