Console not pairing since update to 12.0.0

[thxomas]

I had a working setup on rpi3B with some issues, and after dist-upgrade (bad idea), I cannot connect anymore from the Grip/Order menu.

Joycontrol is indefinitely waiting for Switch to connect :

• hcidump shows request from the Switch, but after some exchanges, it terminates after passkey sent (HCI Auth Failure, Remote Terminated)
• I found that the Device Class is not properly set (even if the command returns correct in python, hciconfig shows 0x000000. Setting manually to 0x002508 is reset to 0x000000 when re-running joycontrol). That may explain the Authentication Failure.
• so now I have doubts about the bluez5 (don't know my previous version), but the SDP seems correctly set (Nintendo Wireless Gamepad with L2CAP+HIDP) However, the AuthenticationRequired=False may not be honoured, another possible explanation to the Auth Failure

[EDIT: unrelated issue fixed.]

I'm trying to fix this before being able to troubleshoot amiibo_writing again. :)

[thxomas]

Update : fixed Device Class setting by doing it AFTER hid.discoverable() in server.py

However, still no pairing from the switch, here is the end of hcidump :

> HCI Event: User Confirmation Request (0x33) plen 10
    bdaddr 94:58:CB:XX:XX:XX passkey 185519
< HCI Command: User Confirmation Request Negative Reply (0x01|0x002d) plen 6
    bdaddr 94:58:CB:XX:XX:XX
> HCI Event: Command Complete (0x0e) plen 10
    User Confirmation Request Negative Reply (0x01|0x002d) ncmd 1
    status 0x00 bdaddr 94:58:CB:XX:XX:XX
> HCI Event: Simple Pairing Complete (0x36) plen 7
    status 0x05 bdaddr 94:58:CB:XX:XX:XX
    Error: Authentication Failure
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 12 reason 0x13
    Reason: Remote User Terminated Connection

The rpi seems to reject the passkey although the AuthenticationRequired=False flag. So nothing happens at python level.
Investigating if this is a new default behaviour of the bluez version.

T

[thxomas]

OK, what's the practice on git ? Rename an issue or create a new one ?
I didn't notice the update to 12.0.0... 🤔 so this issue is merely caused by the console, not linux...

[thxomas]

Went a step further in the pairing process, by setting a bt-agent to accept the passkey.
Next step is failing after " Link Key Notification"

[thxomas]

If anyone interested : After gathering info from various projects, I managed to get the amiibo_writing branch work on raspberry pi 3, latest raspbian buster.
Amiibo read/write is not yet functional, but initial pairing works and then using reconnect gives a stable connection to the switch (I was able to launch BOTW from Home menu, load a save, and trigger amiibo reading, but was greeted by "Connect a controller that can read amiibos...").

Please be aware it is still manual, and not ready for easy sharing. Steps to reproduce :

• Change RPi BT MAC address to get in Nintendo OUI range : I just changed the first 3 byte of the original to 94:58:CB
  hcitool cmd 0x3f 0x001 0xbe 0x13 0x37 0xCB 0x58 0x94 (MAC bytes in reverse order
  or
  use the bdaddr tool
• Disable extra SDP Profiles by setting ExecStart command in systemd /lib/systemd/system/bluetooth.service to :
  ExecStart=/usr/lib/bluetooth/bluetoothd -C -P sap,input,avrcp
• Force default device class (I noticed bluez tends to set this value at unwanted times) in /etc/bluetooth/main.conf :
  Class = 0x002508
• Set default hostname in /etc/machine-info :
  PRETTY_HOSTNAME=Pro Controller
• Configure an Agent to negotiate pairing security : I used the test/simple-agent provided in bluez source, and slightly modified it to accept anything without blocking prompt. Launch it in the background.
  ./simple-agent &
• Modify server.py by swapping hid.discoverable() and set_class()

        # start advertising
        hid.discoverable()

        # set the device class to "Gamepad/joystick"
        await hid.set_class()

When this is done : try pairing..
sudo ./run-controller.py PRO_CONTROLLER
and go to Grip Screen, connection works ! However if you send 'a' command, the menu exits, but "ERROR - Connection lost"

Now if you reconnect with -r option, the connection keeps ON, until trying NFC read/write.

Of course, these steps should be in some way integrated to the project, but at least the POC is done.
Another drawback, is that the RPi is somewhat dedicated only to emulating a joycon, and trying any other BT service would break it..

Thanks to @Brikwerk from NXBT project for having found the missing information to reach this state

ref. Brikwerk/nxbt#18

I need amiibos back ! 💪
T.

[pokemon-bot]

I am trying your solution on my HP laptop with intel bluetooth on ubuntu and I followed your steps but I got stuck
this file is missing /etc/machine-info
and where do I get test/simple-agent ? and what is the modification I need to change ?

[thxomas]

I am trying your solution on my HP laptop with intel bluetooth on ubuntu and I followed your steps but I got stuck
this file is missing /etc/machine-info

This file is specific to the RPi I think. this is the way bluez gets the hostname for bluetooth. On Ubuntu, you may check /etc/bluetooth/main.conf for the Name setting (top of file, just before "Class")

and where do I get test/simple-agent ? and what is the modification I need to change ?

The file is an example found in the bluez source package. I attached my (dirty) modified version to this comment (rename .py or remove extension) Unlike joycontrol it runs on python2, you may need to apt install python-bluez

simple-agent.txt

Does the MAC Address change have an effect on the Intel chipset ?
Good luck
T.

[thxomas]

Run joycontrol, then, in another shell session, check your controller status by comparing to this :

/home/pi# bluetoothctl show

Controller 94:58:CB:96:BC:79 (public)           #MAC Address must be in Nintendo OUI range
        Name: Pro Controller                    #Name and Alias like a true controller
        Alias: Pro Controller
        Class: 0x00002508                       # Set by joycontrol
        Powered: yes
        Discoverable: yes
        Pairable: yes
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)   # Default profile (accepted by switch)
        UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb)   # Gamepad profile set by joycontrol
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)   # Default profile (accepted by switch)
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)   # Default profile (accepted by switch)
        Modalias: usb:v1D6Bp0246d0532
        Discovering: no

The simple-agent must be running detached, or in another session, it will auto accept pairing. Once paired, you don't need it to be running to reconnect with -r option.

T

[JaredEzz]

Thanks to @thxomas for providing steps to troubleshoot.

1. Change RPi BT MAC address to get in Nintendo OUI range
I installed the libbluetooth-dev & bdaddr tools to help with this, follow instructions here.
I'm using a raspberry pi 2 with a usb bluetooth connector, this was the info before the change:

Manufacturer:   Cambridge Silicon Radio (10)
Device address: 00:1A:7D:DA:71:13

and after the change:

Manufacturer:   Cambridge Silicon Radio (10)
Device address: 00:1A:7D:DA:71:13
New BD address: 94:58:CB:DA:71:13

Address changed - Reset device manually

2. Disable extra SDP Profiles
I changed ExecStart in /lib/systemd/system/bluetooth.service from
ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=input to
ExecStart=/usr/lib/bluetooth/bluetoothd -C -P sap,input,avrcp

3. Force default device class
I changed Class in /etc/bluetooth/main.conf (under the [General] section at the top) from
#Class = 0x000100 to
Class = 0x002508

4. Set default hostname in /etc/machine-info
I also did not find the machine-info file on my raspberry pi, could be because of the linux version, rpi version, etc.
I changed Name in /etc/bluetooth/main.conf from
Name = BlueZ to
Name = Pro Controller

5. Configure an Agent
I copied the contents of the prived simple-agent.txt into simple-agent on my rpi, made it executable and ran it, and got some missing packages errors. I installed the recommended package python-bluez, as well as python-gobject, python-dbus because of import errors, and I got the following error:

ERROR:dbus.proxies:Introspect error on :1.5:/org/bluez: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.39" (uid=1001 pid=1087 comm="/usr/bin/python ./simple-agent ") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply="0" destination=":1.5" (uid=0 pid=280 comm="/usr/lib/bluetooth/bluetoothd --noplugin=input ")
Traceback (most recent call last):
  File "./simple-agent", line 161, in <module>
    manager.RegisterAgent(path, capability)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in __call__
    **keywords)
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 2 matched rules; type="method_call", sender=":1.39" (uid=1001 pid=1087 comm="/usr/bin/python ./simple-agent ") interface="org.bluez.AgentManager1" member="RegisterAgent" error name="(unset)" requested_reply="0" destination=":1.5" (uid=0 pid=280 comm="/usr/lib/bluetooth/bluetoothd --noplugin=input ")

Moving on to try the rest without the agent but wanted to post in case there's a simple fix for this error

[thxomas]

Try sudo or running the agent as root

[JaredEzz]

6. Modify server.py by swapping hid.discoverable() and set_class()
did this ^^ self-explanatory

FINAL
ran sudo ./run-controller.py PRO_CONTROLLER and it ran as expected. Paired, connected, then disconnected after a command or two.
Then ran the command with the -r flag and everything works as expected! Turns out I didn't need the agent. Thank you so much @thxomas

[thxomas]

For more insights if you want, find and install bluez-utils, to get tools liike btlon or btmgmt. They give good clues to the cause of problems (Switch not connecting at all, Authentication errors, etc...)

[JaredEzz]

I spoke too soon. It disconnected after a minute or so

[thxomas]

Good and bad news !
Looks like we will have to deal with the command rate spottef by NXBT 😭

Maybe @Poohl will look into it ?

[JaredEzz]

ran bluetoothctl show and it looks like the Alias is properly set but the name and class did not set correctly

[JaredEzz]

I manually added a machine-info file in /etc and added the PRETTY_HOSTNAME to it. That fixed the Name issue. Connection is still lost after a few commands however. Looking for a solution to the Class problem.

These are the relevant lines in my server.py

        # start advertising
        hid.discoverable()

        # setting bluetooth adapter name and class to the device we wish to emulate
        await hid.set_name(protocol.controller.device_name())
        await hid.set_class()

and again, in my /etc/bluetooth/main.conf
Class = 0x002508

@thxomas any thoughts?

[JaredEzz]

sudo hciconfig hciX class 0x002508 changes the class, but the connection still drops after a minute or two

[Poohl]

Wait, wait. Sorry for beeing late didn't get notified of the name change.

So do I get this right: @thxomas got it working again just by messing with the Bluetooth pairing process and not modifying the input frequency (or to much inside joycontrol in general)?

Since NXBT's solution is to limit the speed to 15Hz and 1hz before pairing, that can be done aswell but I highly doubt that this is how it should be done. I'll check old captures to check for something we might be doing wrong, @Brickwerk speculated here that it might be to do with the timing byte or some timing in general.

I updated my switch while I was away too, damm it.

[JaredEzz]

@thxomas figured out how to pair it again. I can pair and connect again with -r but the connection only lives as long as I stay in the switch menus. Entering a game causes the connection to fail

[JaredEzz]

I noticed that the list of UUIDs is different when connecting the first time and reconnecting. The Human Interface Device UUID isn't present when I bluetoothctl show after reconnecting

[JaredEzz]

Any ideas on how I can apply the sdp_record_hid.xml manually? Not having any luck googling. I'm trying to do it with sdptool

[thxomas]

@thxomas figured out how to pair it again. I can pair and connect again with -r but the connection only lives as long as I stay in the switch menus. Entering a game causes the connection to fail

Entering Zelda:BOTW does not disconnect, I'm so lucky :)

I noticed that the list of UUIDs is different when connecting the first time and reconnecting. The Human Interface Device UUID isn't present when I bluetoothctl show after reconnecting
Any ideas on how I can apply the sdp_record_hid.xml manually? Not having any luck googling. I'm trying to do it with sdptool.

I think no need to. SDP is intended for discovery only, once paired, the Switch will remember the UUIDs and PSM to connect to.

[JaredEzz]

OK, well Pokemon Sword/Shield disconnects :( probably the frequency issue. Just for fun, I connected to Zelda:BOTW and it works fine. I'll test some other games rn too.

[thxomas]

So do I get this right: @thxomas got it working again just by messing with the Bluetooth pairing process and not modifying the input frequency (or to much inside joycontrol in general)?

Yes sir ! The new pairing has additional security (PIN&Encryption) and the console does not tolerate much deviation from a true controller (Name, SDP profiles, ...). But I focused on BotW and apparently got lucky. I did not tinker with any core joycontrol logic as I don't get it yet.
One paired, data exchange and controller init work well.

Since NXBT's solution is to limit the speed to 15Hz and 1hz before pairing, that can be done aswell but I highly doubt that this is how it should be done. I'll check old captures to check for something we might be doing wrong, @Brickwerk speculated here that it might be to do with the timing byte or some timing in general.

I'll try to help you in the timing byte analysis when I understand it ;)

[Poohl]

@thxomas First I'm trying to get anything back to work. I followed @JaredEzz steps but my bluetooth adapter isn't complying. I have a raspi 4, but apparently these also have issues with that on top of the incredibly spotty wifi/bluetooth chip on there. Will take some time.

What I found about the timing byte: The switch just increments it by one each message, the joycon (right joycon) increments it by 1 every 0.005 seconds, but increments it a lot more on input mode changes or some MCU commands. Since the joycons run at 60hz, that means incrementing it by 3 every report seems sensible.

[pokemon-bot]

I tried

sudo ./bdaddr -i hci0 -r 94:58:CB:01:02:03
Manufacturer:   Intel Corp. (2)
Device address: 10:4A:7D:01:02:03
Unsupported manufacturer

and

sudo hcitool cmd 0x3f 0x001 0x94 0x58 0xCB 0x01 0x02 0x03
< HCI Command: ogf 0x3f, ocf 0x0001, plen 6
  94 58 CB 01 02 03 
> HCI Event: 0x0f plen 4
  01 01 01 FC 

both did not work in changing the mac address of my intel bluetooth. I think I may need to get a usb bluetooth now

[Poohl]

@pokemon-bot Same problem here. If you find one that works please tell me which one (brand, model/type) because if my raspi won't cooperate either I gotta buy one :(

For the record:

• random Qualcomm-card inside my Acer laptop doesn't work
• Gigabyte PCI-E with Intel chipset never worked

[pokemon-bot]

I am starting to think that bluetooth might be harder than emulating wired controller via arduino. I did a quick search and found this. Anyone tried this ? https://github.com/HackerLoop/Arduino-JoyCon-Library-for-Nintendo-Switch

[Yamakaky]

BTW I can't manage to reconnect the devices, I have to remove and pair them each time.

[Poohl]

@Yamakaky The good news: I got it working after presumably 4 BlueZ devs. I had to convert it to UDP instead of TCP, because L2CAP is frame based and when using queues+asyncio even without nagle's algorithm linux starts combining frames in TCP. That also improved lag and stability quite a bit, since UDP is generally more similar to L2CAP. (will push soon)
However I only got it working with the reconnect option, as the pairing is just way to spotty for me. This wasn't really a problem, the datarate is really managable (I tried with 2 bt-controllers, one on a raspi, one on my Desktop. ping between both machines is 0.2ms).
I tried going around the Homescreen and started untitled Goose game, all without issue (and without Max Slots Changes).
Now the very bad news: After the max slots change event it just instantly kicks the proxy just like the simulated controllers (i tried to read an amiibo in the settings). However it does not reliably trigger that event when connecting a new controller. (it worked once and kicked me twice).
This means whatever causes the disconnect is either a) not propagated by the proxy or b) already has too much lag. Considering the shitshow that is this protocol's timing and the fact that I captured the end closer to the switch I'm heavily siding for a). While the SR, SL and ZR buttons seem to indicate something on the Pairing screen I can't find anything in the trace I got now that would indicate any change at the ACL layer or higher. Meaning something is going on in the lower Bluetooth levels. And the only things lower than ACL is HCI, H4 and the Air...
In the process I also noticed one more thing: You can send completely malformed input reports as long as they are valid L2cap (start with a1) the switch will keep the connection.

[Poohl]

Ok Great news: the Grand Patch is live, please everyone try the following:

sudo run_controller_cli.pi PRO_CONTROLLER
(read/react to prompts if you get any, feedback is appreciated)
(wait for the 4 print messages)
click up
pause
click a (to leave the pairing screen)
unpause

And to read amiibos:

nfc <amiibo_dump.bin> (or use the --nfc argument)
pause
click <whatever it takes to start the reading, usually A>
unpause

Try the same for writing amiibos. Untested yet. It is important, that whenever you want to enter any amiibo-screen you are paused.

In general that is the main new thing. When you are paused the switch doesn't axe the connection (at least for a while), so whenever you come to some moment where you assume it's about to happen, try to pause. Note however that anything using the gyro this might not work or result in eradic movement. Also while paused anything but the buttons don't work.
Any feedback regarding success/faliure is appreciated. Most notably any pauses you had to insert into whatever you are usually doing would be appreciated to figure out what and where it needs automating.

Also another debug feature is in there:

debug X

sets the input frequency to XHz, if you get a lot of running too slow warnings.

[mbacalan]

I had to give it a few tries and follow the instructions on #4, even though it felt a little random as to why it connected then and why it didn't before, I was able to move around in Animal Crossing and use an NFC too! I did get a disconnection after using the NFC but unlike before, it did read the NFC before disconnecting and I could reconnect right away using the -r parameter.

So this looks like a great work to me. Thanks a lot @Poohl !

One question, I do get a lot of running too slow warnings but in what range should I try using debux X command?

[mbacalan]

BTW, tried it with Zelda BotW too and NFC worked once but can't get it to work again, tried 4 times with disconnections. Game says use a controller that supports NFC or not have the Pro Controller charging.

For reconnecting, I have to close the game or it will error immediately.

[Poohl]

@mbacalan officially the debug X argument should be 60 for joycons or 120 for the pro controller, but that sometimes doesn't work. Still don't know why. Sometimes you have to go as low as 4 to get rid of the errors.
And just as a warning: anything below 1 works, but makes everything really unresponsive.
Also just to clarify: you got disconnects while paused? Instantly as before or after a few seconds beeing paused? Try waiting a bit before starting the read, it takes a while until the pause takes effekt on the hardware. (You can open Wireshark and see when the packets stop)
And for the weird "not an nfc controller" problem please see #5. Still no idea there.

[mbacalan]

@Poohl yes, I have tried again now with longer times after pausing. It did work once again but couldn't get it to work again even after rebooting both devices and trying multiple times. So that seems to be a little random, at least with BotW. ACNH worked on first try, not sure if it was coincidence or not.

The disconnect happens while paused / without using unpause.

[Yamakaky]

On my side, the pairing works, but the connection is lost as soon as I leave the pairing screen:

[17:40:41] root _reply_to_sub_command::191 INFO - received Sub command SubCommand.ENABLE_6AXIS_SENSOR
[17:40:41] root _reply_to_sub_command::191 INFO - received Sub command SubCommand.ENABLE_VIBRATION
[17:40:41] root _reply_to_sub_command::191 INFO - received Sub command SubCommand.SET_NFC_IR_MCU_CONFIG
[17:40:41] root _reply_to_sub_command::191 INFO - received Sub command SubCommand.SET_PLAYER_LIGHTS
This shuld be false: True
[17:40:41] joycontrol.protocol _writer::151 INFO - writer started
[17:40:41] joycontrol.protocol _pair_inputter::130 INFO - pairing writer started
shouldnt be here
shouldnt be here
shouldnt be here
shouldnt be here
click up
cmd >> pause
cmd >> click a
cmd >> [17:40:59] joycontrol.transport read::118 ERROR - No data received.
[17:40:59] joycontrol.protocol connection_lost::249 ERROR - Connection lost.
[17:40:59] asyncio default_exception_handler::1738 ERROR - Task exception was never retrieved
future: <Task finished name='Task-246' coro=<L2CAP_Transport.close() done, defined at /home/mikael/dev/python/joycontrol/joycontrol/transport.py:189> exception=AttributeError("'NoneType' object has no attribute 'cancel'")>
Traceback (most recent call last):
  File "/home/mikael/dev/python/joycontrol/joycontrol/transport.py", line 196, in close
    if self._read_thread.cancel():
AttributeError: 'NoneType' object has no attribute 'cancel'

[mbacalan]

@Yamakaky this happened to me once on initial pairing (opening the controllers menu) but after that, I'm able to connect using the -r MAC_ADDR flag.

[Poohl]

Even more amazing news: It's now fully automated. I got the lag in Linux under control and could implement a transport-level fix.

Why transport level is good: no game specific detection necessary, no input, output or whatnot dependencies to check. No need to handle NFC-reading, NFC-writing, Pairing etc... Let's hope that's really it.
Only caveat: you'll get a warning that the code is running very slow every time this fix kicks in.

[mbacalan]

@Poohl latest version is working perfectly for me, amazing work! Connecting with -r flag never fails and I used over 10 NFC reading with no disconnects or any other issues.

[dtrunk90]

Hey guys. You don't have to mess with Mac addresses. Changing the device class is enough to be able to connect again.

[thxomas]

@Poohl wow, GG on the great progress !

Just tested the Grand V12 Fix on RPi4 : both joycons attached, pairing at 1st attempt and still on the initial connection 25 min later ! After exiting Grip menu, I started ACNH, read an amiibo card, back home, managed to write to a card, swapped to BOTW, runs OK. goes to controller screen if I use the joycons, and finally crashed some way. After easy reconnect, amiibo use is OK !

Some rare "Code too slow" (a burst when reconnecting while ingame)

This issue is gonna close soon... 👏
@thxomas

[Poohl]

@thxomas Yes, am doing a bit of polish and final testing currently. Just read, wrote and re-read 3 amiibos. Paired and reconnected no problem. Went in and out of game, etc.
The "please press R+L on the first controller screen" always has been a problem, no clue how the joycons salvage that one.
Plan of action on my end:

• touchup the transport code (the _flow_control_??? stuff is a huge mess)
• touchup the server (suppress questions to user when used as library)
• remove dead code from protocoll (there is an anticipate command in there that doesn't work)
• merge everything back into amiibo_edits.
• Close this and the NFC issue
• update pull requests

Still TODO:

• go into 60hz mode when leaving the pairing screen
• clean shutdown of the dozens of aio tasks
• update documentation, i added an -r auto option
• remove the pause command. They act on protocoll level and might still be usefull.

[Poohl]

Ok, I can pair and reconnect, write amiibos etc no problem.

For now I consider this closed.

[Venryx]

@Poohl Are the instructions in this repo's readme still sufficient for v12.0.1?

Or are there additional instructions (or no-longer-needed instructions) that still need to be merged?

[Poohl]

@Venryx The instructions in the readme should still work, but joycontrol will now also try to fix these things itself or warn you (wt least when using the cli).
I'll update the readme tomorrow.
The only thing notably different to the doc are the dependencies. you need

• hcitool or bdaddr
• hciconfig
• systemctl

Whether any of these changes are no longer needed only further testing will tell. @dtrunk90 stated that the MAC-stuff is uneccessary. Someone else reported success with the old Plugin-setup. I had success without the Name change.

It might be the old steps are still all you need and everything else is just panic-fixes for nonexistent problems. Will test a bit the next week.

[munichi-jasuda]

I can now successfully connect to my Switch using the latest version by Poohl, but can't read Amiibo. Connection closes when attempting to read Amiibo. (I have also changed the ExecStart parameters in bluetooth.service, bluetooth MAC address using the change_btaddr.sh, and bluetoothctl system-alias).

[thxomas]

Ouch, v12.0.2 is available... misclick, big sweat.... but everything you fixed seem to work in this new version.

[munichi-jasuda]

The v12.0.2 makes changes to Bluetooth Driver. Is it safe to update or should I stick to v12.0.1?

[Poohl]

@munichi-jasuda

Connection closes when attempting to read Amiibo.
That looks like #5, and we still don't really know what the issue is.
You too can try to start tshark before joycontrol and send me the capture. I currently can't reproduce it so this is the best i can offer regarding debugging.

[munichi-jasuda]

I think the problem is definitely with the device class. Even after changing the MAC address and successfully connecting with the Switch, the device is eventually identified as invalid when reading NFC.

I ran the bluetoothctl show command both before and after successfully connecting with my Switch, and it seems my device class is unaffected (0x001c0000). It's not 0x2508, as it should be in order to be identified as a valid controller that can read Amiibo.

[dtrunk90]

Mac address changing can only be considered as a workaround as you can Set the Mac address to one of your Real controllers who already got paired successfully to the switch. If you then connect with a Mac address of one of your Real controllers switch Firmware doesn't check the device class for pairing. So this is only bypassing the device class check when pairing. The Real solution is only to change the device class. That's what we already found out with Joycon Droid.

[Poohl]

@dtrunk90 So even the SDP-changes are unnecessary? Meaning the switch will pair despite too many capabilities, a non-nintendo mac and a random name and alias, as long as the class is ok? or is the Alias still required?

[dtrunk90]

@dtrunk90 So even the SDP-changes are unnecessary? Meaning the switch will pair despite too many capabilities, a non-nintendo mac and a random name and alias, as long as the class is ok? or is the Alias still required?

I can only speak for pairing because i dont have the joycondroid Source Code. But yes, for pairing only the device class is needed. Nothing else. We made a magisk module in order to be able to keep using joycondroid.

[Poohl]

@dtrunk90 Thanks for the info, i updated #4 and pushed a commit to server.py to no longer mess with the mac.

[thxomas]

I tested too : Changing the MAC is not mandatory after all.