bluez
bluez copied to clipboard
bluez
3rd Party Wii-U Controller Not Pairing
The short version of this issue is that I have this "Wireless Pro Gamepad" controller that won't pair. I have other Wii-U controllers that do, but this one is different somehow. One thing that's weird about this is that the kernel actually finds it when it's plugged into USB, but the firmware on it identifies it as something completely different.
I typed out my attempts at making it work here: https://github.com/dvdhrm/xwiimote/issues/66#issuecomment-775176154
I think the best bet at making this thing work would be to continue the effort at expanding the wiimote plugin to allow for a possible USB connection and have it whitelist automatically from there, and I also expect there may be some "magic" bit involved, as we have seen in other driver requirements.
I wanted to make sure I put all this detail into one place so that someone else having this issue can pick this up. For now, this gamepad will be given to my kids to play with (and likely destroy)
Here is all the detail about this controller that I was able to pull:
40:F4:07:CD:4A:0D` clock offset: 0x32d9 class: 0x002504
[General]
Name=Nintendo RVL-CNT-01-UC
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Class=0x002504
[LinkKey]
Key=DCC9017CAD1A851DA7ADFDA1BA319FD7
Type=0
PINLength=0
Name: Nintendo RVL-CNT-01-UC
Alias: Nintendo RVL-CNT-01-UC
Class: 0x00002504
Icon: input-gaming
Paired: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
BD Address: 40:F4:07:CD:4A:0D
OUI Company: Nintendo Co., Ltd. (40-F4-07)
Device Name: Nintendo RVL-CNT-01-UC
LMP Version: 3.0 (0x5) LMP Subversion: 0xc
Manufacturer: IACA electronique (771)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slave>
```
As a side comment - I really wish there was a way to tell bluetoothctl to include LIAC results when you run "scan on". I haven't been able to find a way to make that happen. So I have to run hcitool inq -iac=liac separately to acquire the macs before trying to pair them, and sometimes they don't show up while scanning at all until hcitool cc <MAC> is run immediately.
Well the the logs suggests it is able to pair, perhaps you are not able to connect to it after that? Can you collect an HCI trace using btmon? That should give us some indication of what could be the problem.
If I just hit sync on this gamepad it doesn't show up in btmon or hcidump when I "scan on" from bluetoothctl.
However, when I use "hcitool inq --iac=liac" then I see the following results:
> HCI Event: Inquiry Result with RSSI (0x22) plen 15
bdaddr 40:F4:07:CD:4A:0D mode 1 clkoffset 0x4dc8 class 0x002504 rssi -31
> HCI Event: Inquiry Result with RSSI (0x22) plen 15 #114 [hci0] 232.158630
Num responses: 1
Address: 40:F4:07:CD:4A:0D (Nintendo Co., Ltd.)
Page scan repetition mode: R1 (0x01)
Page period mode: P2 (0x02)
Class: 0x002504
Major class: Peripheral (mouse, joystick, keyboards)
Minor class: 0x01
Limited Discoverable Mode
Clock offset: 0x4dc8
RSSI: -31 dBm (0xe1)
I cannot pair using bluetoothctl at all because the devices never shows up, instead I have to use "hcitool cc 40:F4:07:CD:4A:0D" and then I these results:
< HCI Command: Create Connection (0x01|0x0005) plen 13 #1 [hci0] 11.768281
Address: 40:F4:07:CD:4A:0D (Nintendo Co., Ltd.)
Packet type: 0xcc18
DM1 may be used
DH1 may be used
DM3 may be used
DH3 may be used
DM5 may be used
DH5 may be used
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
Role switch: Allow slave (0x01)
> HCI Event: Command Status (0x0f) plen 4 #2 [hci0] 11.781131
Create Connection (0x01|0x0005) ncmd 1
Status: Success (0x00)
> HCI Event: Connect Complete (0x03) plen 11 #3 [hci0] 15.390017
Status: Success (0x00)
Handle: 71
Address: 40:F4:07:CD:4A:0D (Nintendo Co., Ltd.)
Link type: ACL (0x01)
Encryption: Disabled (0x00)
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2 #4 [hci0] 15.390386
Handle: 71
> HCI Event: Command Status (0x0f) plen 4 #5 [hci0] 15.395007
Read Remote Supported Features (0x01|0x001b) ncmd 1
Status: Success (0x00)
> HCI Event: Read Remote Supported Features (0x0b) plen 11 #6 [hci0] 15.405019
Status: Success (0x00)
Handle: 71
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
Encryption
Slot offset
Timing accuracy
Role switch
Sniff mode
Power control requests
Power control
Enhanced inquiry scan
Interlaced inquiry scan
Interlaced page scan
AFH capable slave
< HCI Command: Remote Name Request (0x01|0x0019) plen 10 #7 [hci0] 15.405155
Address: 40:F4:07:CD:4A:0D (Nintendo Co., Ltd.)
Page scan repetition mode: R2 (0x02)
Page scan mode: Mandatory (0x00)
Clock offset: 0x0000
< ACL Data TX: Handle 71 flags 0x00 dlen 10 #8 [hci0] 15.405190
L2CAP: Information Request (0x0a) ident 1 len 2
Type: Extended features supported (0x0002)
> HCI Event: Number of Completed Packets (0x13) plen 5 #9 [hci0] 15.409017
Num handles: 1
Handle: 71
Count: 1
> HCI Event: Command Status (0x0f) plen 4 #10 [hci0] 15.412006
Remote Name Request (0x01|0x0019) ncmd 1
Status: Success (0x00)
> HCI Event: Remote Name Req Complete (0x07) plen 255 #11 [hci0] 15.439999
Status: Success (0x00)
Address: 40:F4:07:CD:4A:0D (Nintendo Co., Ltd.)
Name: Nintendo RVL-CNT-01-UC
@ Device Connected: 40:F4:07:CD:4A:0D (0) flags 0x0000
17 09 4e 69 6e 74 65 6e 64 6f 20 52 56 4c 2d 43 ..Nintendo RVL-C
4e 54 2d 30 31 2d 55 43 NT-01-UC
< HCI Command: Disconnect (0x01|0x0006) plen 3 #12 [hci0] 17.406272
Handle: 71
Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4 #13 [hci0] 17.409939
Disconnect (0x01|0x0006) ncmd 1
Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4 #14 [hci0] 17.487949
Status: Success (0x00)
Handle: 71
Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 40:F4:07:CD:4A:0D (0) reason 2
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr 40:F4:07:CD:4A:0D ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 71 bdaddr 40:F4:07:CD:4A:0D type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 71
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 71
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 40:F4:07:CD:4A:0D mode 2 clkoffset 0x0000
< ACL data: handle 71 flags 0x00 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 71 packets 1
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 40:F4:07:CD:4A:0D name 'Nintendo RVL-CNT-01-UC'
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 71 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 71 reason 0x16
Reason: Connection Terminated by Local Host
It is possible to "trick" bluetoothctl - if I run "pair 40:F4:07:CD:4A:0D" while the hcitool is in the middle of trying to complete a connection, then bluetoothctl will see the device and attempt to pair/connect. It will get as far as saying it's connected, but the kernel never sees a new device and the gamepad's lights just continue to blink until they time out and turn off.
I'm also one from the thread in xwiimote with a 3rd party Wiimote with motion plus and have been following that issue for years. This is my basic hcitool response
BD Address: 00:17:AB:39:C5:44
OUI Company: Nintendo Co., Ltd. (00-17-AB)
Device Name: Nintendo RVL-CNT-01
LMP Version: 3.0 (0x5) LMP Subversion: 0xc
Manufacturer: IACA electronique (771)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slave>
BD Address: 00:17:AB:39:97:61
OUI Company: Nintendo Co., Ltd. (00-17-AB)
Device Name: Nintendo RVL-CNT-01
LMP Version: 3.0 (0x5) LMP Subversion: 0xc
Manufacturer: IACA electronique (771)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slav
So if there is any testing or data I can do from my side to help you figure it out just tell me what commands to run and I will try to.
I have that same 3rd party Wii U Pro controller (mine has 40:F4:07:CD:ED:44). I was able to get it to work. There are a lot of obstacles involved, however:
- Firstly, the controller is not discoverable. This could be worked around by simultaneously sending fake beacons from a Raspberrypi with the same MAC address (only for short durations 0.1secs and without allowing connections). It will take several tries, but eventually can be discovered and paired (also did this on Windows). I was not able to get Bluez to ask for the sdp records successfully though.
- The device can alternatively be paired by using hcitool cc... followed by hcitool auth... and having hard patched the Bluez stack to make the pin callbacks work for this.
- When the controller is powered on after being paired, it will immediately connect back to the paired Host on PSM 0x13
- Bluez (version 5.50) fails to accept this connection, because the device has not been initialized before. Here is debug output:
bluetoothd[4633]: profiles/input/server.c:connect_event_cb() Incoming connection from 40:F4:07:CD:ED:44 on PSM 17 bluetoothd[4633]: profiles/input/device.c:input_device_set_channel() idev (nil) psm 17 bluetoothd[4633]: Refusing input device connect: No such file or directory (2)
- Once I hard patched the code to just get the connection and also faked its sdp record, the device will be whitelisted to the kernel
- I then needed faked the VID/PID to be as Nintendo controller, as the 3rd party controller has no VID/PID
- hid-wiimote kernel module will then talk to the device
- hid-wiimote is not able to get the controller working, because
- The response report for "Register Read" has a shorter length than specified in the handler table, thus the correct handler is never called
- Once I hard-patched that, it was recognized as "Wii U Pro controller". But the device never sends Data Reports!
- I found out, that it needs Data Report Mode (DRM) set to 0x3D (default for original controller is 0x34). After setting that, it will send the Data reports, which finally match those of original Nintendo Wii U pro controller
- I was content and stopped here, because my target is Windows.
- hid-wiimote is not able to get the controller working, because
As I use the controller on Windows, I can not come up with code for bluez and/or hid-wiimote. IMHO the issues above, especially pairing and the connecting of the controller are conficting with bluez stack as is. Probably would be necessary to write a complete new plugin to handle all this.
@rfzjrn4vec do you have some code ?
i'm trying to do the same exercice with a 3rd party wiimote. (not wii-u) but i've the same issues, but it doesn't work yet on my side. i can pair. i add the uuids, vip and pid, but the kernel module still won't load.
my patch for the moment is:
//
char devname[64];
device_get_name(device, devname, 64);
if(strncmp(devname, "Nintendo RVL-CNT-01", 19) == 0 && btd_device_get_vendor(device) == 0 && btd_device_get_product(device) == 0) {
{ FILE* fd=fopen("/tmp/debug.log", "a"); fprintf(fd, "Nintendo 3rd party wiimote detected\n"); fclose(fd); }
btd_device_set_pnpid(device, 2 /* source */, 0x057e /* USB_VENDOR_ID_NINTENDO */, 0x0306 /* USB_DEVICE_ID_NINTENDO_WIIMOTE */, 0x0600 /* version */);
device_set_class(device, 0x2504 /* input-gaming */);
btd_device_add_uuid(device, "00001000-0000-1000-8000-00805f9b34fb"); // Service Discovery
btd_device_add_uuid(device, "00001124-0000-1000-8000-00805f9b34fb"); // Human Interface Device
btd_device_add_uuid(device, "00001200-0000-1000-8000-00805f9b34fb"); // PnP Information
}
//
