20 Jun 2013 02:56
[BUG] HCI_RESET and Num_HCI_Command_Packets limit
Hello, I'm experiencing a problem that wedges the bluetooth adapter from time to time. The repro case can be hit with this scenario: run bluetoothd while hciconfig hci0 up && hciconfig hci0 down; do echo -n .; done In few iterations you will have a timeout while trying to bring up the interface. This is just a repro case, the real scenario just happens from time to time if you for instance restart bluetoothd at the right (or wrong!) moment. The problem is the following: Setting up the interface, the host will send several HCI commands to set things like the device class or the local name. If it happens that the hciconfig makes the host send a HCI_Reset command after another command was sent but before the corresponding event was received, then the adapter is blocked for a while. Recovery it from that situation is kind of random. A few attempts of hcidump hci0 up may or not work.... but the problem was before. In the hci trace you see below, the last HCI Event received has a value of Num_HCI_Command_Packets of 1, which according to the Core spec (Vol2, part E, sec 7.7.14) means that we can only send 1 HCI command until we receive the next event; but the trace shows that we sent 2: Write Local Name and a Reset. So the host here doesn't follow the spec... am I right? Even worse, after the HCI_Reset the host shall not send additional HCI(Continue reading)
RSS Feed