DS5 to PS5 Proxy

[InhexSTER]

Hi,

Just wanted to open separate thread from DS4Windows.

So what I am using right now is:

1. Raspberry Pi with latest Raspbian 32 bit
2. Asus USB BT 4.0 dongle (hci1)

I setup link key for PS5 like this:

[LinkKey]
Key=PS_LINK_KEY_HERE
Type=4
PINLength=0

[General]
Name=
SupportedTechnologies=
Trusted=true
Blocked=false

DS5 was paired using share+options method and this file was generated, unmodified, it is paiered with internal
BT on RPi (hci0)

[General]
Name=Wireless Controller
Class=0x002508
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=00001124-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[DeviceID]
Source=2
Vendor=1356
Product=3302
Version=256

[LinkKey]
Key=DS5_KEY_HERE
Type=4
PINLength=0

hcitool is not available instead there is btmgmt on latest distro

sudo btmgmt --index 1 power off

sudo btmgmt --index 1 public-addr {DS5_PAIRED_WITH_PS5}

This changes the BT dongle address to DS5 address that I paired with PS5

sudo systemctl stop bluetooth

sudo btmgmt --index 0 power on
sudo btmgmt --index 1 power on

sudo ./l2cap_proxy {PS5_BT_ADDR} {DS5_PAIRED_WITH_PS5} 0x002508

Initially I was able to get some connection established, but I can't replicate that anymore.
During that time it seems that it was not being reset by PS5

Now I am always getting this:

listening on psm: 0x0001
listening on psm: 0x0005
listening on psm: 0x0007
listening on psm: 0x000f
listening on psm: 0x0011
listening on psm: 0x0013
listening on psm: 0x0015
listening on psm: 0x0017
listening on psm: 0x0019
listening on psm: 0x001b
listening on psm: 0x001d
listening on psm: 0x001f
listening on psm: 0x0021
accepted connection from DS5_ADDR (psm: 0x0001)
connecting with DONGLE_ADDR to PS5_ADDR (psm: 0x0001)
connected to  PS5_ADDR (psm: 0x0001)
poll error from SLAVE (psm: 0x0001)
accepted connection from  DS5_ADDR (psm: 0x0011)
connecting with  DONGLE_ADDR to  PS5_ADDR (psm: 0x0011)
accepted connection from  DS5_ADDR (psm: 0x0013)
connecting with DONGLE_ADDR  to  PS5_ADDR(psm: 0x0013)
connection failed: Connection reset by peer
connection failed: Connection reset by peer
connected to PS5_ADDR  (psm: 0x0011)
connected to PS5_ADDR  (psm: 0x0013)
poll error from MASTER (psm: 0x0011)
poll error from MASTER (psm: 0x0013)

accepted connection from DS5_ADDR (psm: 0x0001)
connecting with DONGLE_ADDR  to PS5_ADDR   (psm: 0x0001)
connected to PS5_ADDR  (psm: 0x0001)
poll error from SLAVE (psm: 0x0001)
accepted connection from DS5_ADDR  (psm: 0x0011)
connecting with DONGLE_ADDR  to PS5_ADDR   (psm: 0x0011)
accepted connection from DS5_ADDR  (psm: 0x0013)
connecting with DONGLE_ADDR  to PS5_ADDR   (psm: 0x0013)
connection failed: Connection refused
connected to PS5_ADDR   (psm: 0x0011)
connection failed: Connection refused
poll error from MASTER (psm: 0x0011)
connected to PS5_ADDR   (psm: 0x0013)
poll error from MASTER (psm: 0x0013)

[InhexSTER]

Seems that after I called

sudo btmgmt --index 1 keys
sudo btmgmt --index 1 ltks

It doesn't disconnect right away but seems to time out

in the btmgt I see this:

hci1 class of device changed: 0x002508
hci1 PS5_ADDR  type BR/EDR connected eir_len 15
hci1 PS5_ADDR  auth failed with status 0x05 (Authentication Failed)
hci1 PS5_ADDR  type BR/EDR disconnected with reason 0

I am pretty sure my link key is correct, but I will re-capture it again later today

EDIT:

New key didn't help
Also with keys reloaded
I see this in l2cap_proxy log

connecting with DONGLE_ADDR to PS5_ADDR (psm: 0x0013)
connection failed: Function not implemented
connection failed: Function not implemented
connected to PS5_ADDR (psm: 0x0011)
connected to PS5_ADDR  (psm: 0x0013)
poll error from MASTER (psm: 0x0011)
poll error from MASTER (psm: 0x0013)

[matlo]

A device address is unique, it can't be used by two nearby devices. It is expected to have connection issues in such case. This means you either need a second DS5 or a way to pair another address with the PS5.

[InhexSTER]

I have 2 DS5 controllers
I am not using DS5 that was paired with PS5 at the time. it's off.

I am using BTAddr of that controller on a dongle

DS5 I am using to connect to RPi has completely different BT address

[matlo]

Are you sure device class is 0x2508? Did you get the changes from #4 ?

[matlo]

At the time I used hcidump together with wireshark to check were the communication was failing.

[InhexSTER]

It seems that DS5 controller disconnects right away if I use 0x2508 or 0x508 as device class
If I set to the same value as original dongle's class id it seems that DS5 stays connected for a bit until PS5 times out
I have no idea how it "worked" at some point.
My guess would be that as soon as DS5 poll fails it closes all connections and that why I am seeing auth fail on PS5 in btmgt log

How were you pairing dongle at DS5?
I found a way to set pairing info over USB, just like in DS4, just on different report ID

[InhexSTER]

Something strange with repeating USB pairing flow I capture from PS5:

Controller paired with Linux at first with auto-generated key and it works

1. Change to custom link key in /var/lib/bluetooth/.....
2. Restart Bluetooth (controller fails to connect as expected)

Using USB cable on different machine
2. Set master + custom link key using 0x10 report // same byte format as DS4
3. Call 0x08, 0x2 (report 8) //????
4. Call 0x08, 0x1 (report 8) //Turns on Bluetooth
5. Controller flashes and connects to back to Linux box

After this the custom key in /var/lib/bluetooth/..... is replaced with completely brand new key

So this makes me think that there was some link key manipulation in the controller, however how that key would get into config file I have no clue

I did upgrade both controllers last night on PS5, so maybe that is causing additional issues

[InhexSTER]

Somewhat good news as PS5 supports DS4 I've tried GIMX DS4 BT mode connecting from PC to console over bluetooth works with PS5
I assume wired connection would work too
That means PS4 titles can still be played with keyboard an mouse on PS5

This is very promising, that means the proxying can work, and I might be able to capture the BT packets.

[InhexSTER]

So it clear that my setup /dongle should be able to do BT proxying. I think its something to do with l2cap_proxy or configuration. Maybe I am missing some step or putting the link keys to wrong location.
I tried same setup with DS4 and PS5 and l2cap_proxy was giving same poll error form slave.

[InhexSTER]

From the hcidump I think DS5 itself disconnects (Rcvd Disconnection Request) after receiving SDP / Service Search Attribute response form PS5 (`170 byte)

[fraca7]

Hi there. A couple remarks:

• Report 8 seems to be the same as report 0x14 on the PS4/Dualshock (see https://dsremap.readthedocs.io/en/latest/reverse.html#boot-sequence-ps4) so if you get the 0x2/0x1 sequence of set_reports that means that the console re-paired the controller.
• On the PS4/Dualshock side, the SDP channel is indeed closed by the console after the initial handshake. I guess the PS5/Dualsense would do the same.
• Setting your dongle's address (didn't know you could do that) means that you now have two devices having the same address; I think this may cause problems, those are supposed to be unique for a reason :)

I'm starting to work on PS5 support for dsremap myself so I may have more to add later.

[fraca7]

For the record: the PS5 seems to have 2 Bluetooth addresses. They use the same link key. If you look at the hcidump you'll notice a failed link key negotiation for the second address; the PS5 closes the existing connections after that (thus your "Poll error"). When the key is configured for the second address, after the client (Dualsense) has connected to PSMs 0x11 and 0x13, the Playstation itself connects to it on those same PSMs, from its second address. As l2cap_proxy is designed to only handle one connection per PSM, things go south from there:

accepted connection from D0:BC:C1:0C:0D:47 (psm: 0x0001)
connecting with (null) to DC:E9:94:AC:29:DC (psm: 0x0001)
connected to DC:E9:94:AC:29:DC (psm: 0x0001)
poll error from SLAVE (psm: 0x0001)
accepted connection from D0:BC:C1:0C:0D:47 (psm: 0x0011)
connecting with (null) to DC:E9:94:AC:29:DC (psm: 0x0011)
accepted connection from D0:BC:C1:0C:0D:47 (psm: 0x0013)
connecting with (null) to DC:E9:94:AC:29:DC (psm: 0x0013)
connected to DC:E9:94:AC:29:DC (psm: 0x0011)
connected to DC:E9:94:AC:29:DC (psm: 0x0013)
accepted connection from DC:E9:94:AC:29:DD (psm: 0x0011)
psm already used: 0x0011
accepted connection from DC:E9:94:AC:29:DD (psm: 0x0013)
psm already used: 0x0013

Here the PS5's addresses are DC:E9:94:AC:29:DC and DC:E9:94:AC:29:DD. I'm going to dig a little deeper...

[matlo]

Maybe you could handle further connections with a second l2cap_proxy instance + a second bluetooth dongle?

[fraca7]

Good idea, I'll try this

[fraca7]

Nope, doesn't work; if the Dualsense is paired with dongle 1 and the PS5 with dongle 2, the PS5 does not accept incoming connections from dongle 1 (first proxy instance). Anyway I hacked up a proxy that supports multiple host/device pairs and managed to go further:

pi@raspberrypi:~/dev/dsremap/src/proxy/build $ sudo ./bt-proxy -k D0:BC:C1:0C:0D:47,deadbeefdeadbeefdeadbeefdeadbeef -k DC:E9:94:AC:29:DD,51c88db1765d6c525707bf81ff094da6 -k DC:E9:94:AC:29:DC,51c88db1765d6c525707bf81ff094da6 -p D0:BC:C1:0C:0D:47,DC:E9:94:AC:29:DC -p DC:E9:94:AC:29:DD,D0:BC:C1:0C:0D:47
[info] Adding key deadbeefdeadbeefdeadbeefdeadbeef for bdaddr D0:BC:C1:0C:0D:47
[info] Adding key 51c88db1765d6c525707bf81ff094da6 for bdaddr DC:E9:94:AC:29:DD
[info] Adding key 51c88db1765d6c525707bf81ff094da6 for bdaddr DC:E9:94:AC:29:DC
[info] Adding proxy link from D0:BC:C1:0C:0D:47 to DC:E9:94:AC:29:DC
[info] Adding proxy link from DC:E9:94:AC:29:DD to D0:BC:C1:0C:0D:47
[info] Listening on PSM 0x01
[info] Listening on PSM 0x11
[info] Listening on PSM 0x13
[info] New connection from D0:BC:C1:0C:0D:47, PSM 0x01; forwarding to DC:E9:94:AC:29:DC
[info] Connecting to DC:E9:94:AC:29:DC PSM 0x01
[info] Successfuly connected to DC:E9:94:AC:29:DC PSM 0x01
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DC - 0x01: 20 bytes
[debug] 06 00 01 00 0f 35 03 19 01 00 08 00 35 05 0a 00 00 ff ff 00
[debug] DC:E9:94:AC:29:DC -> D0:BC:C1:0C:0D:47 - 0x01: 161 bytes
[debug] 07 00 01 00 9c 00 99 36 00 96 36 00 52 09 00 00 0a 00 01 00 0a 09 00 01 35 03 19 12 00 09 00 04
[debug] 35 0d 35 06 19 01 00 09 00 01 35 03 19 00 01 09 00 09 35 08 35 06 19 12 00 09 01 03 09 02 00 09
[debug] 01 03 09 02 01 09 05 4c 09 02 02 09 0d 56 09 02 03 09 05 00 09 02 04 28 01 09 02 05 09 00 02 36
[debug] 00 3e 09 00 00 0a 00 01 00 30 09 00 01 35 03 19 18 01 09 00 04 35 13 35 06 19 01 00 09 00 1f 35
[debug] 09 19 00 07 09 00 01 09 ff ff 09 00 05 35 03 19 10 02 09 02 00 19 10 02 09 ff ff 35 03 19 10 01
[debug] 00
[info] New connection from D0:BC:C1:0C:0D:47, PSM 0x11; forwarding to DC:E9:94:AC:29:DC
[info] Connecting to DC:E9:94:AC:29:DC PSM 0x11
[info] New connection from D0:BC:C1:0C:0D:47, PSM 0x13; forwarding to DC:E9:94:AC:29:DC
[info] Connecting to DC:E9:94:AC:29:DC PSM 0x13
[info] Successfuly connected to DC:E9:94:AC:29:DC PSM 0x13
[info] Successfuly connected to DC:E9:94:AC:29:DC PSM 0x11
[debug] DC:E9:94:AC:29:DC -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b 20 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DC - 0x11: 65 bytes
[debug] a3 20 4e 6f 76 20 32 30 20 32 30 32 30 31 32 3a 35 39 3a 35 35 02 00 04 00 13 03 00 00 37 00 00
[debug] 01 41 0a 00 00 00 00 00 00 00 00 00 00 10 02 00 00 2a 00 01 00 06 00 01 00 06 00 00 00 06 a8 10
[debug] 15
[info] New connection from DC:E9:94:AC:29:DD, PSM 0x11; forwarding to D0:BC:C1:0C:0D:47
[info] Connecting to D0:BC:C1:0C:0D:47 PSM 0x11
[info] Successfuly connected to D0:BC:C1:0C:0D:47 PSM 0x11
[info] New connection from DC:E9:94:AC:29:DD, PSM 0x13; forwarding to D0:BC:C1:0C:0D:47
[info] Connecting to D0:BC:C1:0C:0D:47 PSM 0x13
[info] Successfuly connected to D0:BC:C1:0C:0D:47 PSM 0x13
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b 05 29 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 42 bytes
[debug] a3 05 fd ff f6 ff f4 ff a9 22 50 dd 7f 22 6a dd 7a 22 71 dd 1c 02 1c 02 1f 20 1c e0 62 1f 60 df
[debug] fe 1f fb df 08 00 7f d6 a8 ec
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b 20 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 65 bytes
[debug] a3 20 4e 6f 76 20 32 30 20 32 30 32 30 31 32 3a 35 39 3a 35 35 02 00 04 00 13 03 00 00 37 00 00
[debug] 01 41 0a 00 00 00 00 00 00 00 00 00 00 10 02 00 00 2a 00 01 00 06 00 01 00 06 00 00 00 06 a8 10
[debug] 15
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 65 bytes
[debug] 53 f0 01 01 00 01 00 00 00 c6 05 38 f7 99 f1 28 21 2d 6e dc c2 31 7f dd f4 10 00 01 00 00 00 00
[debug] 00 00 00 00 00 00 00 00 00 30 30 30 31 30 30 30 31 30 30 30 30 30 30 30 30 bb 3d 50 84 71 7e 91
[debug] 98
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 1 bytes
[debug] 00
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 65 bytes
[debug] 53 f0 01 01 01 36 61 c6 72 b1 e9 22 44 de 06 75 f8 9b f0 ea 7f 6b 49 cd 63 d4 2b 25 ad dd 3a 34
[debug] eb f9 07 b2 0c 46 5d 52 b0 33 5d 11 da 37 2d 62 c3 cc 44 09 37 35 4e 59 25 80 2d c2 7a 92 17 37
[debug] 8e
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 1 bytes
[debug] 00
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 65 bytes
[debug] 53 f0 01 01 02 ce a4 0f d2 a0 11 56 2c 2b f2 69 70 de bd 4a 49 eb b1 17 cf 92 2a ec 63 a9 37 77
[debug] 7a 31 e1 61 1a 84 48 ba 1d 37 05 6a c2 61 05 67 85 c6 54 70 22 a8 fe 73 9b 2e 9b 8e f1 59 5b 23
[debug] db
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 1 bytes
[debug] 00
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 65 bytes
[debug] 53 f0 01 01 03 43 59 41 74 96 91 ec ea 49 f2 6d b9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[debug] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c4 46 72
[debug] 41
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 1 bytes
[debug] 00
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f2 10 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 17 bytes
[debug] a3 f2 00 01 12 20 32 30 20 32 30 32 30 0f 7a 39 d2
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f1 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 65 bytes
[debug] a3 f1 01 01 00 95 9a 99 0e e0 9f 56 45 66 c8 04 b4 fa 5f 5d 44 10 00 02 00 00 00 00 00 00 00 00
[debug] 00 00 00 00 00 30 30 30 32 30 30 30 31 30 31 31 45 37 35 33 42 e8 64 3e 11 ee 26 87 59 28 3e 9c
[debug] 62
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f1 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 65 bytes
[debug] a3 f1 01 01 01 0c 21 df c1 c9 e4 5f 98 43 be 34 62 bc f9 89 da 20 8c 4a 19 77 36 95 31 ef 43 d5
[debug] 81 7d d9 fc 48 64 e4 aa 83 87 5a 52 f4 aa c6 9f 7f b1 5f ef 61 92 2f 40 b2 01 32 0a 63 5a 41 f2
[debug] ec
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f1 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 65 bytes
[debug] a3 f1 01 01 02 c8 d6 45 63 db 0b 15 25 9e 92 2c dd ef b1 bd 34 56 b1 48 b9 e0 da e2 ad a9 d2 c5
[debug] 3e 4c 6e 3d 30 2d ad 09 7e 5f bc fd 66 70 b3 76 6b 60 c7 18 0d 79 dc 5a 5c 79 26 7c 8d 54 5c da
[debug] 0c
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f1 40 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 65 bytes
[debug] a3 f1 01 01 03 ff ec 51 58 41 dc 3a f3 71 57 40 50 6d 91 37 1c 9d 92 cc 85 ae 51 c4 6f a9 d2 c5
[debug] 3e 4c 6e 3d 30 2d ad 09 7e 5f bc fd 66 70 b3 76 6b 60 c7 18 0d 79 dc 5a 5c 79 26 7c 8d eb 0c 4b
[debug] 8d
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 65 bytes
[debug] 53 f0 02 01 00 d6 18 44 1a 43 b2 fa 1f 2b 56 b8 b4 46 d0 33 c1 01 00 00 00 00 00 00 00 00 00 00
[debug] 00 3e b5 a7 7a 00 e6 f1 cf 2f 8b 1e 39 a1 2d 08 4f 00 00 00 00 00 00 00 00 00 00 00 00 d0 32 2b
[debug] 64
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 1 bytes
[debug] 00
[debug] DC:E9:94:AC:29:DD -> D0:BC:C1:0C:0D:47 - 0x11: 4 bytes
[debug] 4b f2 10 00
[debug] D0:BC:C1:0C:0D:47 -> DC:E9:94:AC:29:DD - 0x11: 17 bytes
[debug] a3 f2 00 01 40 ff ec 51 58 41 dc 3a f3 12 47 90 b3

So, the PS5 does indeed "call back" to the Dualsense on PSMs 0x11 and 0x13, and uses those channels for the initial reports (0x05 IMU calibration data, 0x20 manufacturing info) and the auth challenge. There are still a few strange things, like the DS stops sending input reports altogether, but it may be a problem on my side, I'll play with this next week-end