04-19-2016, 04:00 PM
joshg, #5 seems to be related to MTU configuration option. It was already implemented in L2CAP_Configuration_Request, but not L2CAP_Configuration_Response...
Here is sample response with this option.
=== HCI header ===
02 2a 20 12 00 0e 00 01 00 - HCI header, as above, please see the L2CAP CONNECTION REQUEST packet structure
=== Actual L2CAP command ===
05 L2CAP_CMD_CONFIG_RESPONSE
4c Packet identifier
0a 00 Command payload length
40 00 SCID (Source Channel Identifier, in other words, local endpoint ID)
00 00 Flag 0
00 00 Result 0 (success)
01 Config Opt: type = MTU (Maximum Transmission Unit) - Hint
02 Config Opt: length
3c 00 MTU
joshg
PANHAI update from my side: I got it working wireless and with bluetooth.
I apologize upfront as this is going to get a little technical .... but hopefully not too much!
I set up Wireshark with USBPCap in Windows and ran a capture of the bluetooth traffic by having it capture traffic on the USB bluetooth adapter itself, while attempting to connect the controller through bluetooth.
Then also used Wireshark with libpcap in Linux and did the same thing - captured traffic on the USB interface for the bluetooth adapter.
Using this I was able to determine exactly where they are different. Because in Linux it had a lot of built in parsing, plus the libpcap is different than usbpcap used for windows, the output was a little different. So I had to comb through quite a bit and spent about 3 hours analyzing the flow and the individual bytes to finally find where exactly they are different.
So in general different in these few places:
1) When L2CAP_Connection_Request is received, Linux sixad daemon only sends a single L2CAP_Connection_Response with "success" whereas in Windows ScpToolkit is sending 2 individual L2CAP_Connection_Response -- first a "pending" followed by a "success".
2) ScpToolkit L2CAP_Command is defaulting 2nd byte (buffer[1]) of the sent buffer to 0x20 if it is 0x00 ... in Linux sixad it doesn't do this, it always is sending 0x00 .. this is for all sending L2CAP commands
3) ScpToolkit L2CAP_Configuration_Request has hard-coded byte of 0x96 and 0x00 for bytes 11 and 12 (buffer[10] and buffer[11]) but I noticed in Linux sixad that it seemed to match DCID (e.g. for mine it was sending 0x40, 0x00) so I changed this to dcid[0] and dcid[1] so it would put the dest channel in these bytes instead of this hard-coded value 0x96, 0x00
4) ScpToolkit L2CAP_Configuration_Response in the 3rd byte (buffer[2]) I noticed in linux for me it was sending 0x0a here but ScpToolkit has this hard-coded at 0x06. For now I changed it to hard-coded 0x0a. From what I have poked around, this value could actually be coming from the controller itself when original HCI_Connection_Request or HCI_Accept_Connection_Request event occurs (on mine I am seeing this byte 0x0a coming across as the next byte after the command/event identifier)
5) Also in same method L2CAP_Configuration_Response, in linux sixad they have 4 extra bytes on the end of this buffer that do not exist in ScpToolkit. They are: 0x01, 0x02, 0xa0, 0x02. The origin of these 4 bytes could possibly be similar to last 4 bytes L2CAP_Configuration_Request and maybe especially this byte 0xa0 could be sent from the controller somewhere in the stream but I haven't found it as of yet.
Anyway with making those 5 changes to both BthDongle.Tasks.cs and BthDongle.L2cap.cs my PANHAI controllers are working perfectly over bluetooth.
I will try to roll back and maybe make each change one-at-a-time to see if there is one specifically that was the real key or not and post an update shortly
Edit: Ok after trying everything off and on I actually found that only ONE of the above changes is needed and it gets the PANHAI working fine.
It is #5 above -- changing L2CAP_Configuration_Response from host to have 14 length payload instead of 10 with 0x01, 0x02, 0xa0, 0x02. Not sure if each of these values can be hard-coded or if they need to depend on data sent back from the controller, but this should be the only change needed to get PANHAI controllers to connect.
I confirmed by taking a fresh copy of source and only modified BthDongle.L2cap.cs:L2CAP_Configuration_Response and it is working with only this change.
Here is sample response with this option.
=== HCI header ===
02 2a 20 12 00 0e 00 01 00 - HCI header, as above, please see the L2CAP CONNECTION REQUEST packet structure
=== Actual L2CAP command ===
05 L2CAP_CMD_CONFIG_RESPONSE
4c Packet identifier
0a 00 Command payload length
40 00 SCID (Source Channel Identifier, in other words, local endpoint ID)
00 00 Flag 0
00 00 Result 0 (success)
01 Config Opt: type = MTU (Maximum Transmission Unit) - Hint
02 Config Opt: length
3c 00 MTU
joshg
PANHAI update from my side: I got it working wireless and with bluetooth.
I apologize upfront as this is going to get a little technical .... but hopefully not too much!
I set up Wireshark with USBPCap in Windows and ran a capture of the bluetooth traffic by having it capture traffic on the USB bluetooth adapter itself, while attempting to connect the controller through bluetooth.
Then also used Wireshark with libpcap in Linux and did the same thing - captured traffic on the USB interface for the bluetooth adapter.
Using this I was able to determine exactly where they are different. Because in Linux it had a lot of built in parsing, plus the libpcap is different than usbpcap used for windows, the output was a little different. So I had to comb through quite a bit and spent about 3 hours analyzing the flow and the individual bytes to finally find where exactly they are different.
So in general different in these few places:
1) When L2CAP_Connection_Request is received, Linux sixad daemon only sends a single L2CAP_Connection_Response with "success" whereas in Windows ScpToolkit is sending 2 individual L2CAP_Connection_Response -- first a "pending" followed by a "success".
2) ScpToolkit L2CAP_Command is defaulting 2nd byte (buffer[1]) of the sent buffer to 0x20 if it is 0x00 ... in Linux sixad it doesn't do this, it always is sending 0x00 .. this is for all sending L2CAP commands
3) ScpToolkit L2CAP_Configuration_Request has hard-coded byte of 0x96 and 0x00 for bytes 11 and 12 (buffer[10] and buffer[11]) but I noticed in Linux sixad that it seemed to match DCID (e.g. for mine it was sending 0x40, 0x00) so I changed this to dcid[0] and dcid[1] so it would put the dest channel in these bytes instead of this hard-coded value 0x96, 0x00
4) ScpToolkit L2CAP_Configuration_Response in the 3rd byte (buffer[2]) I noticed in linux for me it was sending 0x0a here but ScpToolkit has this hard-coded at 0x06. For now I changed it to hard-coded 0x0a. From what I have poked around, this value could actually be coming from the controller itself when original HCI_Connection_Request or HCI_Accept_Connection_Request event occurs (on mine I am seeing this byte 0x0a coming across as the next byte after the command/event identifier)
5) Also in same method L2CAP_Configuration_Response, in linux sixad they have 4 extra bytes on the end of this buffer that do not exist in ScpToolkit. They are: 0x01, 0x02, 0xa0, 0x02. The origin of these 4 bytes could possibly be similar to last 4 bytes L2CAP_Configuration_Request and maybe especially this byte 0xa0 could be sent from the controller somewhere in the stream but I haven't found it as of yet.
Anyway with making those 5 changes to both BthDongle.Tasks.cs and BthDongle.L2cap.cs my PANHAI controllers are working perfectly over bluetooth.
I will try to roll back and maybe make each change one-at-a-time to see if there is one specifically that was the real key or not and post an update shortly
Edit: Ok after trying everything off and on I actually found that only ONE of the above changes is needed and it gets the PANHAI working fine.
It is #5 above -- changing L2CAP_Configuration_Response from host to have 14 length payload instead of 10 with 0x01, 0x02, 0xa0, 0x02. Not sure if each of these values can be hard-coded or if they need to depend on data sent back from the controller, but this should be the only change needed to get PANHAI controllers to connect.
I confirmed by taking a fresh copy of source and only modified BthDongle.L2cap.cs:L2CAP_Configuration_Response and it is working with only this change.